Messages in this thread | | | From | (Aaron Denney) | Subject | Re: Remote ioctls - [was Re: Adding checkpointing API to Linux kernel] | Date | 24 Jan 1999 04:36:56 GMT |
| |
Note: I don't know who wrote the "> : " prefixed part that Larry quoted.
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/
| |