Re: [9fans] 9p2010

["Fco. J. Ballesteros" <nemo@lsub.org>]

But if you do that (send sequences from userl-level)
you must interpret your namespace yourself. When I tried to
detect how to bundle calls for plan b, a problem I had was
namec. For me it's still not clear how to detect cleanly
`what to batch', even if you change the source for the
program doing I/O to help there, because of the mount
table.


>  From: rogpeppe@gmail.com
>  To: 9fans@9fans.net
>  Reply-To: 9fans@9fans.net
>  Date: Thu Apr 23 19:26:06 CET 2009
>  Subject: Re: [9fans] 9p2010
>
>  2009/4/23 erik quanstrom <quanstro@quanstro.net>:
>  > it occurred to me yesterday morning that the problem with
>  > a bundle of 9p requests is that 9p then no longer maps directly
>  > to system calls.
>  >
>  > with 9p2000, if you want to do a Tread, it's pretty clear that
>  > one needs to read(2); traditiona syscalls map directly to 9p.
>
>  true, but it is a one-to-many mapping - for instance, a single call to
>  open may generate an arbitrary number of 9p messages.
>
>  > not so when bundles/sequences are introduced.  how does a
>  > user program generate an arbitrary bundle?  can programs
>  > use bundles at all without being rewritten?
>
>  this is an interesting question.
>
>  as a starting point, i'd envisaged simply changing the existing
>  system calls to do sequences.
>
>  in inferno, where it's easy to add system calls, it would be
>  straightforward, i think, to add some additional system-level primitives,
>  (e.g. readfile) that took advantage of sequencing.
>  but that is cheating really - ideally you'd want a user-level
>  interface to this functionality.
>
>  the difficulty with creating the interface is that a 9p call
>  must be separated into two parts - the sending of the
>  parameters and the retrieving of the results.
>
>  for a low level 9p interface, i'd imagined something like
>  the following interface (in pseudo limbo):
>
>  Sequence: adt {
>  	queue: fn(seq: self ref Sequence, m: Tmsg, tag: any);
>  	wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg);
>  	cont: fn(seq: self ref Sequence);
>  	flush: fn(seq: self ref Sequence);
>  }
>
>  queue adds a new message to the sequence (with an arbitrary
>  tag to attach to the result of the call). wait waits for the next
>  reply to come in and returns the tag, the originating tmsg and the
>  reply. cont continues executing a sequence after it has
>  been aborted due to error (this will resend tmsgs). flush aborts
>  the sequence.
>
>  so this is ok when dealing with 9p or the dev interface directly, but
>  won't work so well
>  with higher level calls. it would be nice for a user-level program to
>  be able to string together an arbitrary sequence of system calls
>  into a sequence, but i'm not sure what a decent interface would look like.
>  (something like the above Sequence adt, but with a system call description
>  instead of Tmsg and a system call result instead of Rmsg, perhaps,
>  although it's not clear what a "system call description" would look like,
>  or how easy it would be to split system calls)
>
>  the control flow is not straightforward (or perhaps it is - it's the kind
>  of thing that might just have a nice elegant solution lurking there somewhere).
>
>  something to think about.