Re: no version magic, tainting kernel.

[Joel Becker <Joel.Becker@oracle.com>]

On Sun, Jan 26, 2003 at 03:46:30PM -0600, Kai Germaschewski wrote:
> it have added -DKBUILD_BASENAME and -DKBUILD_MODNAME, which are required 
> by the new module code. And, how did they avoid subtle breakage like not 
> giving the same switches on the command line? (This list goes on...)

	As opposed to the kernel forcing subtle breakage by specifying
options that break said module?  Don't say that doesn't happen (just
like the kernel has to add/remove compiler switches to make some of its
code work).

> Okay, you have a point here, there's still a bug. vermagic.o will be 
> rebuilt when the version changes or any of the recorded config options 
> change, but it doesn't pick up changes in the compiler version, if the 
> new gcc has the same name.

	IOW, you not only need a kernel source tree (built, no less,
taking up space) but it needs to be writable!

> o One thing I do not understand at all: What is the problem with using
>   the internal build system? It makes maintainance of external modules
>   much easier than keeping track of what happens in the kernel and
>   patching a private solution all the time.

	Well, the Red Hat kernel tree is designed to allow you to build
against there UP, SMP, and large memory kernels from one tree.  In your
example, you require three(!) fully built kernel trees lying around, each
with a different configuration.  That's a lot of space.
	Granted, Red Hat (as our example) can do what they have to do,
since the generic kernel isn't responsible for whatever Red Hat does.
However, even without their setup, in 2.4 all I have to do is keep
around version.h and autoconf.h and I can usually do the right thing
with one completely clean kernel tree.

Joel

-- 

"And yet I fight,
 And yet I fight this battle all alone.
 No one to cry to;
 No place to call home."

Joel Becker
Senior Member of Technical Staff
Oracle Corporation
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127