Messages in this thread | | | Date | Fri, 1 Jan 1999 21:47:11 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: bogous binfmt_misc patch in 2.2.0-pre1 |
| |
On Fri, 1 Jan 1999, MOLNAR Ingo wrote: > > yep there are only 40 #if SMP dependencies in the 'main' kernel C files, > and 270 #if PROC_FS dependencies ... thats nonsense.
I hadn't coutned them, but I'm not surprised: when Alan started feeding me the cleanup patches it fairly quickly became obvious that something was wrong.
I don't think all the PROC_FS config issues have to be gone, but yes, they should probably shrink by an order of magnitude. I don't think that should be an impossible goal.
> (the worst #ifdef offender btw. is MODULES, but those are mostly clean and > isolated. Could be solved with a section trick though ...)
I don't worry about MODULE ifconfig's, because those are "local" decisions, really - an issue of whether a single driver is compiled as a module or as a integral part of the kernel. As such it doesn't break any concept of modularity - the difference could be seen as the difference between a global config that impacts things all over (CONFIG_PROC_FS) and tons of small local configs that just share a common concept (MODULE).
One thing I _have_ considered using a "section" trick for is the "init" routines. Right now one of the uglier files is drivers/net/Space.c, which is just endless "#ifconfig"s - and it should be possible to reasonably easily create a section for "device driver probe" addresses, and thus spread out these things into the drivers that actually implement them.
(The same is true of filesystems and memory devices, for example)
However, that's definitely a 2.3 issue. In contrast, the CONFIG_PROC_FS thing could probably be considered just a cleanup patch (I'd think it should be pretty trivial to remove quite a noticeable portion of them with an "obviously correct" kind of patch).
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/
| |