1. 04 Nov, 2010 1 commit
    • David Johnson's avatar
      Allow tiptunnel to set serial device options via capture. · e6a0977e
      David Johnson authored
      For now, I made it possible to set speed of the capture with
      tiptunnel.  Later we could expose more options... but the right
      thing to do is build a ConsoleAgent that is much more flexible.
      I think we now know what we need as far as a good feature set
      for that program.
      e6a0977e
  2. 03 Nov, 2010 1 commit
  3. 02 Nov, 2010 2 commits
  4. 31 Oct, 2010 6 commits
  5. 29 Oct, 2010 9 commits
    • Gary Wong's avatar
      Automate the handout and slide build process. · 61ae568b
      Gary Wong authored
      61ae568b
    • Gary Wong's avatar
      82d64836
    • Jonathon Duerig's avatar
    • Jonathon Duerig's avatar
      More tweaks for GEC9 · 80fdaa74
      Jonathon Duerig authored
      80fdaa74
    • Mike Hibler's avatar
      My old notes about the libvnode API. · cb0b549e
      Mike Hibler authored
      Cons up when I was updating the Xen vnode support last year.
      cb0b549e
    • Mike Hibler's avatar
      Merge remote branch 'central/master' · 2bac630e
      Mike Hibler authored
      2bac630e
    • Mike Hibler's avatar
      Improve regular (non-image) file transfer via frisbee. · 78f3f8d3
      Mike Hibler authored
      Basically, make it possible to transfer a non imagezip image.  Previously
      you had to wrap a regular file as an image in order to transfer it.  The
      big hang up was that the frisbee protocol could only transfer files that
      were a multiple of 1MB (the chunk size).
      
      This commit changes the frisbee protocol slightly to allow transfer of
      non-1MB-multiple files.  The protocol change was to add a new JOIN message
      that returns the size of the file in bytes rather than in blocks.  This
      allows the client to know that the file in question is not a multiple of 1MB
      and allows it to request the correct partial number of blocks for the
      final chunk and to extract the correct amount of data from the final 1K block
      (that block is still padded to 1K by the server).  For the server side, the
      request mostly allows it to do some sanity checking.  The fact that the
      server is started with a file that is not a multiple of 1MB is what triggers
      it to know about partial chunks.  The sanity checking is that the server will
      not acknowledge clients that attempt to join with a version 1 JOIN message,
      since nothing good would come of that pairing.
      
      On the client side, frisbee must be invoked with the -N (nodecompress) option
      in order to issue a v2 JOIN.  See the comment in the code for the rationale,
      but it is largely a backward compat feature.
      
      While I was changing the JOIN message, I added a couple of other future
      features.  One is that by passing back a 64-bit value for the size of the
      image in bytes, we can feed bigger images.  However there is still much to
      be done to realize this.  The other was to add blocksize/chunksize fields
      in the message so that the server/client can negotiate the transfer parameters,
      e.g., 1024 blocks of 1024 bytes vs. 256 blocks of 8192 bytes, the latter being
      for "jumbo" packets on a Gb ethernet.  But there is still more to be done to
      get this working too.
      78f3f8d3
    • Leigh Stoller's avatar
    • Mike Hibler's avatar
      Fix a couple of comments. · 0569e748
      Mike Hibler authored
      0569e748
  6. 28 Oct, 2010 11 commits
  7. 27 Oct, 2010 2 commits
  8. 26 Oct, 2010 7 commits
  9. 25 Oct, 2010 1 commit