Messages in this thread | | | Date | Fri, 1 Jan 1999 11:04:20 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: bogous binfmt_misc patch in 2.2.0-pre1 |
| |
On Fri, 1 Jan 1999, Richard Guenther wrote: > > Could you please revert the patch you got for binfmt_misc? > Its wrong as it leaves binfmt_misc in a completely unusuable > state if CONFIG_PROC_FS is not set. (patch to revert the > changes and one pending change from me (remove stale variable) > is attached)
Reverted - it's better to get a compile-time error than then at run-time get a non-working binfmt_misc and sit there wondering what the h*ll happened.. Let us not forget that compile-time errors may be embarrassing, but they are still a hell of a lot better than bad run-time behaviour.
Let this be a warning to people: avoiding compile time errors at all cost is potentially MORE buggy than just letting it break when somebody selects config combinations that do not make sense.
However, I didn't actually apply the makefile or config patches. I've grown tired of the problems with CONFIG_PROC_FS showing up everywhere (it's been implicated in just about 90% of all CONFIG_XXXX problems I've heard of lately), and I want something better.
That "something better" would be to just make everybody act as if CONFIG_PROC_FS is always there, but for people who really don't want to have the code you just have the register/unregister/whatever functions be empty inline functions that always return success (or failure, whatever).
That way we can get rid of this horrible mess with CONFIG_PROC_FS all over the place in areas that really shouldn't need to care. The fact that so many of them have been wrong for so long implies that nobody really wants to live without /proc, and going to all this trouble to make us able to config it out is not worth it.
Look at the approach taken by the SysV IPC code: if it is configured out, it still leaves the stub routines around so that nothing else has to even _know_ that it doesn't exist. That's what the concept of modularity is all about.
Anyway, I'll leave it with the (unimportant) compile-time problem for now, and hope that that will encourage somebody will fix this properly.
Linus
- 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/
| |