Messages in this thread | | | Date | Sun, 20 May 2001 15:11:53 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [RFD w/info-PATCH] device arguments from lookup, partion code |
| |
On Sun, 20 May 2001, Linus Torvalds wrote:
> 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. Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |