On Wed, 2003-12-03 at 20:59, David Boyes wrote: > > Instead of two pseudofiles (ctl and data), I would suggest > > using a combination of read()/write() and ioctl(). > > Think of it as a stream. Provide access to the "out of band" data. > > (More below; discussion of multi-stream internet protocols.) > > What if the out-of-band stuff were presented as additional pseudofiles in > the connection directory? Borrowing again from the Plan 9 paper, their TCP > implementation adds a couple more pseudofiles for the out-of-band stuff like > connection endpoint details and connection status. They also add a "listen" > pseudofile, which blocks on open until there is data available (eg a network > server writes an address and port number to the ctl file for a connection > and the does an open on the 'listen' file and waits until something comes > in. Example for IUCV connection:
.... You're trading ioctl magic for filename magic. The fundamental problem here is that Unix would like every object to be a file, and would like every file to be an unstructured byte stream. If you have a need to layer metadata or out-of-band data onto that, you either need to break the idea of having *a* file, or of treating everything exactly *like* a file (where file is defined as a big bag of bytes). I suggest that everyone interested in this discussion read ESR's new _The Art of Unix Programming_, and not just because I got him to change something on page 4 that will bring great glee to the members of this list. In fact, the very problem we're discussing is right there on p. 471: "20.3.7 ioctl(2) and fcntl(2) Are an Embarrassment", augmented on p. 472, "20.3.10 File Systems Might Be Considred Harmful". ESR seems to be a fan of the Plan 9 Approach (which DB is advocating here). Adam
