Re: [9fans] 9p2010

[Eric Van Hensbergen <ericvh@gmail.com>]

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 <rogpeppe@gmail.com> wrote:
> 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.
>
>