> Now, a good way to force the issue may be to just remove the "ioctl"
> function pointer from the file operations structure altogether. We don't
> have to force peopel to use "read/write" - we can just make it clear that
> ioctl's _have_ to be wrapped, and that the only ioctl's that are
> acceptable are the ones that are well-designed enough to be wrappable. So
> we'd have a "linux/fs/ioctl.c" that would do all the wrapping, and would
> also be able to do all the stuff that is currently done by pretty much
> every single architecture out there (ie emulation of ioctl's for different
> native modes).
Pheeew... Could you spell "about megabyte of stuff in ioctl.c"?
> It would probably not be that horrible. Many ioctl's are probably not all
> that much used by any real programs any more. The most common ones by far
> are the tty ones - and the truly generic ones like "FIONREAD" that it
> actually would make sense to generalize more.
Networking stuff. It _is_ used.
> Catching stuff like EJECT at a higher layer and turning THOSE kinds of
> things into real block device operations would clean up drivers and make
> them more uniform.
> Would fs/ioctl.c be an ugly mess of some special cases? Yes. But would
> that make the ugliness explicit and possibly easier to try to manage and
> fix? Very probably. And it would mean that driver writers could not just
> say "fuck design, I'm going to do this my own really ugly way".
How about moratorium on new ioctls in the meanwhile? Whatever we do in
fs/ioctl.c, it _will_ take time.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/