> Hi Pavel,
>
> > PS: How many things would break if we forced ioctls to _always_ pass
> >
> > struct foo {
> > int len;
> > char data[len];
> > } ?
>
> Everything would break. Remember that lots of programs use terminal
> control ioctls.
>
> So far I've seen two design ideas. One is an new 'nioctl' system call
> which takes 'len' as a fourth parameter. The other is to add
> 'ioctl_register' and 'ioctl_unregister' to the kernel, so that the
> kernel knows this information and can export it, even though the
> information is not present in the API.
These can't accomplish the same thing: ioctl_register won't help the ioctl
handler figure out how many bytes you passed it for a variable-length
block. If the registration mechanism would simplify some other stuff, go
right ahead, but I'd definitely like to see an nioctl, and similar
routines anywhere that length isn't explicity passed.
Also, 2.0.x, at least, had some places where routines used the MM layer to
calculate a true maximun length for a buffer. While accurate, this is a
remarkable amount of work to go to because a length field wasn't
available, and also broke for uClinux. Note that this was actually in the
fs code, and not actual ioctls. sys_mount is one these, but you might be
surprised at the others: every syscall that takes a filename.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- 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/