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: rogpe...@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 <quans...@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.
