Re: [RFC] KBUILD 2.5 issues/regressions

[Alistair J Strachan <alistair@devzero.co.uk>]

On Friday 11 July 2003 18:47, Arjan van de Ven wrote:
> On Fri, 2003-07-11 at 19:40, Alistair J Strachan wrote:
> > o The state of kbuild in shipped (distribution) kernels must be such that
> > the construction of external modules can be done without having to modify
> > the shipped kernel-source package.
>
> that is actually not hard; I just did this in a RH rpm like way last
> week.

I cannot see how you can make modversions modules without first building
vmlinux. This "RPM" presumably does not ship with vmlinux constructed, and
modpost depends on vmlinux to extract dependency symbols (as far as I can
tell.. though a KBUILD run on an uncompiled modversions tree appears to work,
you'll find the modversions section is not added to the kernel module, note
the size difference).

Try it with the NVIDIA driver, or any other preexisting driver using kbuild
and modversions but lacking a prebuilt vmlinux. I don't use RH, but
presumably the distributed 2.4 kernels did not have to be built before you
could include modversions.h. Assuming modpost is now a replacement for
modversions.h, and it does require vmlinux to include symbol CRCs, no, I
would say there was a problem.

> > So far, this matches the behaviour in 2.4. However, in 2.4 you need only
> > do a "make dep" (and, I believe, some distros also touch a couple of
> > other files).
>
> you never ever should need to do make dep in distro trees for building
> external modules.

Probably not, but what I meant was that supporting files (such as autoconf.h
and other "generated" headers that ARE required for compilation) would be
made during such a stage in 2.4 and do not have to be rebuilt. This isn't
actually the main issue, but I did notice that modpost is sometimes rebuilt
when you call the kernel makefile with SUBDIRS=/to/external/directory, and I
think it's obvious that this will require write access to the tree.

Cheers,
Alistair.