Re: [9fans] ideas for helpful system io functions

[roger peppe <rogpeppe@gmail.com>]

2009/12/7 Nathaniel W Filardo <nwf@cs.jhu.edu>:
>> fd1 := open("/foo1", ORDWR);
>> fd2 := open("/foo2", ORDWR);
>> fd3 := fdjoin(fd1, fd2);
>>
>> what is going to happen?
>> something has got to initiate the requests to actually
>> shift the data, and it's not clear which direction the
>> data will flow.
>
> "file to file" joins like that are not the typical case and might even be an
> error to attempt.

in plan 9, everything is a file - whether it's generated by opening '#p/data1'
or '/foo1'.

>  Linux's equivalent APIs (yes, plural, sigh) always hook
> an "active" component somewhere...  sendfile() for example is typically
> employed as a crude hook on the TCP stack's "I could accept some bytes from
> a write() from userland now" "event" and turn that into a read() of the
> sendfile()d thing (which must be a pagecacheable thing... wtf.  splice()
> fixes at least some or perhaps all of that).  splice()d file descriptors
> just forward read()s and write()s across the splice.

i see why you might want to send file descriptors around
the place, (for instance, one could theoretically add a control
request to /net/tcp that said "treat this fd as your source of data",
though it wouldn't work across the network),
but i still don't see how "splice" could work in general.

>> this is an optimisation, right? what parts of the current system
>> could be speeded up by the use of this primitive?
>
> A typical *nix use case is sending a prefix and static file to a socket
> (e.g. nonencrypting, nonchunked httpds, ftpds, etc.).

well, that case is easily dealt with with something like devjoin.

> Of note, more generally, splice() and friends are approximating something
> possible and (relatively) easy in the capability kernel world: some process
> has capabilities to two objects and wishes to introduce those objects to
> each other (and further wishes that those objects would stop bothering it.
> :) ).  i.e. "Please resend all outstanding and forward all future requests
> to this other capability."

i see that.
but i think that fdjoin(fd1, fd2) is more like introducing two capabilities
to each other, which doesn't really make sense, than talking to the
objects behind the scenes.
the objects behind the scenes in plan 9 are servers and device drivers.

it might be interesting to provide a nice (not /srv based) way of passing
file descriptors between unrelated processes. the challenge comes when
you want to make it
work on a remote file server...