Wow, welcome to my world.
> I also noticed that CVS does not like it if you build in a
> checked-out tree: After that I couldn't "cvs diff" nor "cvs commit",
> because some files were missing beyond include/config in the CVS
> subdirectories. Maybe the Makefiles or Rules can be fixed to avoid
> that problem.
I invented the include/config directory, but I know very little about CVS.
Working together I think we can fix things up.
First let me explain include/config.
The program scripts/split-include.c dynamically creates the include/config
directory and its subdirectory. There is one file in this tree for each
configuration option. Each file has one line recording the current state
of that option.
The timestamps on the files are significant. The idea is: if you change
one configuration option CONFIG_FOO_FAST, then split-include will touch
the file include/config/foo/fast. This will cause the object files that
depend on CONFIG_FOO_FAST to become out of date, and 'make' will recompile
only those files.
The old-fashioned scheme was that almost every object file depended on
include/linux/autoconf.h, so if you changed one option and recompiled,
then 'make' would recompile almost everything, even if 90% of the files
in kernel don't care about CONFIG_FOO_FAST at all.
Ok, so now you have this dynamically created tree. I believe *none* of
it should go into CVS, just like .config and include/linux/autoconf.h
should not be under CVS control.
I am not familiar with .cvsignore and so on. If you can tell me what
files should exist where in this tree, I can modify scripts/split-include.c
to create the necessary files. Or, you could go into scripts/split-include.c
and mail me a patch.
> Anotherthing with versioned symbols: Currently the SMP definition is
> passed as prefix to the genksyms program to prevent crashed due to
> incompatible binaries. IMHO other prefixes for the CPU type or memory
> alignment options (compilation flags) should be passed as well (I once
> had a crash loading i386 compiled modules into a Pentium compiled
> kernel; happens if you use distributions and recompile your kernel)
I suggested the SMP prefix to Alan Cox because I saw a lot of bug
reports about people getting crashes due to mixing SMP modules and
non-SMP kernels, and vice versa. It solves the problem.
The real problem is that an i386 compiled module *should* run on a Pentium
compiled kernel. The kernel API needs to be better documented and more
uniform across configuration changes such as the processor sub-type.
> Unfortunately genksyms just adds prefixes to the name. I haven't
> checked the sources, but it would be more reasonable if all the
> prefixes would be appended to the "mangled name", and then just go
> into the CRC computation.
I think this is a fine idea, but again I say that the real problem
is to identify and minimize the set of sensitive options that need
to go into the CRC.
> I also think the makefile should at least output whether SMP is on or
> not when doing "make config". Also the Makefile could be smart enough
> to do "make mrproper" if necessary to compile after SMP is changed (my
> compilation failed even after a "make clean" when I switched to
> non-SMP. Someone said that "make mrproper" would do the trick).
Pick up a current ac-series kernel and try out my CONFIG_SMP feature,
which is included. And it works great when I switch from CONFIG_SMP=n
to CONFIG_SMP=y or vice versa, without any "make clean" at all, because
"mkdep" in the ac-series generates correct dependencies for every __SMP__
in the source.
Of course if this kind of switching fails for you, or for anyone,
with CONFIG_SMP, send me a bug report. I will be very interested.
> A few dependencies are not yet correct in the Makefile: E.g. when
> building versioned modules, compilation of serial.c failed (I hacked
> it!). After changing only serial.c and restarting make, loop.o was
> also recompiled, even that had been finished before...
Both serial.c and loop.c export symbols. When you turn on
CONFIG_MODVERSIONS, you get a tanker-truck full of extra dependencies.
serial.ver depends on serial.c and modversions.h depends on *.ver.
Every *.o file in the kernel depends on modversions.h.
The problem is that symbol versioning happens at preprocessor time
for both the exporter *and* all of its callers. So if you touch any
file that exports a symbol, you have to recompile every source file
just in case it imports that symbol.
This system was designed before ELF kernels. It would be very good
for someone to redesign the whole CONFIG_MODVERSIONS machinery to use
some ELF magic and clean up these dependencies. I have tried to do
this in the past but I couldn't get the available tools to do what
I needed.
Regards,
Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"
-
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/