lkml.org 
[lkml]   [1997]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.

\
 
 \ /
  Last update: 2005-03-22 13:40    [W:1.327 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site