Messages in this thread | | | Date | Tue, 9 Sep 1997 21:00:36 +0200 | From | Janos Farkas <Janos.Farkas-#uw/> | Subject | Re: CONFIG_SMP patch available for 2.1.54 |
| |
On 1997-09-09 at 10:43:18, David Woodhouse wrote: > My initial thought was to separate each CONFIG_ option into a separate > file, and that source files should only include the files for the > options they depended on: > > #include <linux/config/config_arcnet.h> > #ifdef CONFIG_ARCNET > etc...
As far as I remember, this is considered a good idea, but noone took the stomach to tweak every file just to see that Linus came out with a new patchlevel in the meantime.. :) Another idea that would appeal most, is a modification to mkdepend, or perhaps a separate development tool to check if all the #include <..../config/xxxx.h> files are there for the referenced CONFIG_ variables. This is all quite doable, IMHO. It might also work perfectly for CONFIG_SMP too.
Actually, the only problem which makes every CONFIG_mumble redesign to die a painful death is the module versioning. Many people regard this as an uninteresting feature, and ignore it in their redesigns. Indeed, although it's useful in cases, sometimes it looks very broken. For example, if you modify a file which has the declaration of a modversioned symbol, the .ver file needs to be changed. This, in turn is included in many other headers, so almost all of the kernel and modules needs to be recompiled.
Although this drawback might be avoided by keeping the timestamp of the .ver file if it's not changed (a la GNU move-if-change), but it certainly looks like hacking the hack more. There should probably be a way to move the module versioning into the link stage. In the worst case, it would then cause relinking all modules (or "re-hinting" them with versions), it looks much more reasonable than recompiling most of the kernel because of a dummy change in an essential file. From the technical point of view, I don't know if it's feasible. ELF gurus? :) Is the symbol versioning easily applicable to kernel symbols and modules?
> I don't like this because it means an explosion of small files in the > linux/config directory, which will waste a lot of space on some > filesystems,
It's not *that* bad, unused settings can be linked to the same file, although "insane" filesystems like msdos, don't support links. But anyway, you need hundreds of files to be created for a kernel compile anyway.. :)
> and generally not look nice, but it's a simple way of implementing > finer grained dependencies without overhauling the dependency code.
BTW, sticking to generic mechanisms like the C dependency on headers looks a really clean idea to me.
-- Janos - Don't worry, my address works. I'm just bored of spam.
| |