[lkml]   [1999]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Some very thought-provoking ideas about OS architecture.

On Tue, 22 Jun 1999, Matthew Wilcox wrote:
> Surely the sensible way of doing this is to define an ioctl2() system
> call which is given a length. I imagine we would then add an ioctl2()
> method to struct file_operations, and fall back to ioctl() (trimming
> off the length word) for compatibility.

Actually, for ioctl, you definitely do want to have both a command and a
reply, so something like this would work:

int control(int fd, unsigned int code, void *in, int in_size, void *out, int out_size)

and yes, I agree that "ioctl()" and "fcntl()" as they currently stand are
just horribly ugly, and they are probably one of the worst features of
UNIX as a design.

There's a few other things that could be handled more cleanly with just a
single "control" interface - things like socket options etc (which as they
stand now are yet another special case).

Something like the above is actually what a lot of UNIX systems try to
encode in the ioctl number - the number often has the size and the
direction encoded in it. Linux tries to do it for some things, but it's
not enforced due to historical baggage.

And notice how it's not getting to be really pretty whatever you do: even
if ioctl() and friends had a nicer interface, they'd still be just a ugly
sideband channel to whatever the fd is connected to.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.084 / U:1.608 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site