From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 23 Apr 2009 12:55:42 -0500 Message-ID: From: Eric Van Hensbergen To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] 9p2010 Topicbox-Message-UUID: f189e756-ead4-11e9-9d60-3106f5b1d025 Another alternative (maybe this has already been mentioned -- I haven't been closely following the thread) -- is to integrate the caching into a cache file system. That way you get the advantage for static files (and static file systems) where you have the least opportunity to shoot yourself in the foot by prefetching or making assumptions. No new system calls, no necessary changes to the libraries. -eric On Thu, Apr 23, 2009 at 12:22 PM, roger peppe wrote: > 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. =A0how does a >> user program generate an arbitrary bundle? =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 { > =A0 =A0 =A0 =A0queue: fn(seq: self ref Sequence, m: Tmsg, tag: any); > =A0 =A0 =A0 =A0wait: fn(seq: self ref Sequence): (any, Tmsg, Rmsg); > =A0 =A0 =A0 =A0cont: fn(seq: self ref Sequence); > =A0 =A0 =A0 =A0flush: 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 descriptio= n > 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 somew= here). > > something to think about. > >