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.
