On Sat, 23 Jan 1999 11:55:40 -0800, Larry McVoy <lm@bitmover.com> wrote:
> : BTW things like network block device would benefit from ioctl's being
> : standartized, too. That way, I would be able to pass ioctls across
> : network and I would be able to create network char device and play
> : sounds over network over it :-).
>
> It's cool to see this, somewhere I have a paper on this I wrote at Sun
> when we were thinking about clusters. The bottom line was that we needed
> to migrate all the ioctl's to something that passes in a self describing
> structure. I think we were looking at using something like the Perl
> pack/unpack descriptors which made
[Snip]
> At any rate, it would be very nice to migrate the kernel in this direction.
> It makes it possible for clusters to be a lot more complete.
Instead of ioctls I would actually prefer something akin to to the plan
9 model where each device is actually a directory with two files: a
data file and a control file. Instead of opening the device and
calling ioctls you would instead open the control channel and read()
and write() messages. The big win here would be easy userspace
emulation of (character) devices. The old ioctls could be implemented
as wrappers around reading and writing the control channel.
Passing ioctls across the net becomes as simple as writing a daemon to
monitor a named pipe and forward the messages across the network to
a daemon on the remote machine which would access the real device.
Of course, using a pair of named pipes would only work for emulating
character devices. Perhaps playing around with a mmap()ed regular file
would work to emulate block devices, but this might require too much
overhead.
(Not that I object to your new ioctl interface, or some more standardization
of ioctls. Both would IMHO be useful)
-- Aaron Denney -><-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/