From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 23 Apr 2009 18:22:21 +0100 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9p2010 Topicbox-Message-UUID: f1294df6-ead4-11e9-9d60-3106f5b1d025 2009/4/23 erik quanstrom : > 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. =C2=A0how does a > user program generate an arbitrary bundle? =C2=A0can 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 somewhe= re). something to think about.