On Mon, 27 Jan 2003, Joel Becker wrote:
> 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).
Well, if you're doing things in your module which break with the command
line options the rest of the kernel is using, I'd claim you're playing
tricks in your module which you shouldn't. The only place I'm aware of
where someone really needs to change the options is kernel/sched.c, and
that's a very internal part of the kernel, an area which surely shouldn't
be touched by an external module. (Of course mere adding of -I -Dmacro
happens quite a bit, you can do that for your module as you like)
> > 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!
Basically, yes. The build process needs to be able to write, e.g. to
compile its helper code in scripts/, so init/vermagic.o is just another
file being written.
I guess you'll hate me even more with CONFIG_MODVERSIONING coming back
soon. Because that means that we need to generate the versions checksum
from all the kernel objects, and we need to write the somewhere, too. In
fact, these checksums are generated as part of the compiled objects, so
recording checksums needs all other compiled objects to be around. If you
know a sensible way to get around this limitation, I'd be happy to hear
it, but I fear there isn't.
So it boils down to the fact that we need a full writeable kernel tree. I
agree that this is asking a lot, and I'm sure open for suggestions. The
writeable part can and will be lifted using separate object directories,
which means that the source can remain read-only and you can specify your
own writeable object tree.
> > 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.
As I said, I am sure interested in working with people and distros to get
something which everybody can live with. I'm wondering how RedHat manages
to have one tree for different configurations, since in that case, at
least .config/autoconf.h, EXTRAVERSION and the module version files
(*.ver) need to differ, so that kinda seems not possible in one
(read-only) tree.
Generally, you need to have the configured source around for the kernel
you want to build the module against. If that's three kernels, you need
the source three times. (Or, of course, you reconfigure it between the
builds)
> 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.
And that's with module versioning?
--Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 31 2003 - 22:00:17 EST