![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 12:53 [from the cache] ©2003-2008 | |||||||||||||