From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20091207191129.GD17192@gradx.cs.jhu.edu> References: <20091205031747.GA8759@nipl.net> <20091205194741.0697D5B76@mail.bitblocks.com> <20091207141304.GA28905@nipl.net> <20091207191129.GD17192@gradx.cs.jhu.edu> Date: Mon, 7 Dec 2009 21:03:49 +0000 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] ideas for helpful system io functions Topicbox-Message-UUID: ac5ad2de-ead5-11e9-9d60-3106f5b1d025 2009/12/7 Nathaniel W Filardo : >> fd1 :=3D open("/foo1", ORDWR); >> fd2 :=3D open("/foo2", ORDWR); >> fd3 :=3D 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/dat= a1' or '/foo1'. > =C2=A0Linux's equivalent APIs (yes, plural, sigh) always hook > an "active" component somewhere... =C2=A0sendfile() for example is typica= lly > employed as a crude hook on the TCP stack's "I could accept some bytes fr= om > a write() from userland now" "event" and turn that into a read() of the > sendfile()d thing (which must be a pagecacheable thing... wtf. =C2=A0spli= ce() > fixes at least some or perhaps all of that). =C2=A0splice()d file descrip= tors > 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 proce= ss > has capabilities to two objects and wishes to introduce those objects to > each other (and further wishes that those objects would stop bothering it= . > :) ). =C2=A0i.e. "Please resend all outstanding and forward all future re= quests > 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...