On Sun, Mar 07, 2004 at 02:32:14PM +0100, Andreas Gruenbacher wrote:
>
> > What I have in mind is something like this:
> > - Get rid of current use of SUBDIRS. It is no longer used in any
> > arch Makefiles.
> > - Introduce a KBUILD_EXTMOD variable that is only set when building
> > external modules
> > - Introduce a new method to be used when compiling external modules:
> > make M=dir-to-module
> > - Keeping the SUbDIRS notation for backward compatibility
> > - When using SUBDIRS or M= the 'modules' target is implicit.
>
> Why not keep the SUBDIRS notation for external modules only then? That's
> what was documented to work since a long time; I see no big benefit in
> changing it if it can be avoided.
Since a long time is from 2.5.5x roughly.
The SUBDIRS= notation is not intuitive, and the M= notation follow
the other similar options: O=, C=.
SUBDIRS will be kept, but warned for in 2.7. Removed when 2.8 opens or similar.
So I see no breakage here.
> > - Find a magic way to include a Kconfig file for the external module
>
> This is where it gets pretty messy. You would also have a different
> configuration in the external module. I have no clear idea how that can
> work reasonably cleanly.
If the solution becomes messy then I will just drop it.
I do not see a big need here anyway.
It will also create troubles: Can we modify .config etc.
> > - Allow kbuild Makefiles to be named Kbuild, so local stuff can be in
> > a file named Makefile file
> >
> > note: this can be achieved using makefile/Makefile today but
> > it makes sense since there is not much 'Make' syntax left in
> > kbuild makefiles today.
>
> The Makefile can already include both the kbuild and local stuff (same
> snippet I sent you in personal communication already):
I know - but the incentive here was to seperate stuff out that does not
belong in a Kbuild makefile.
In 2.7 I may write a simple parser to create one single big Makefile,
and then it will be good to have very simple Makefiles only.
> Now with mainline, when building external modules they will end up not
> having modversions. This is caused by the way .tmp_versions is handled,
> and is a real problem. There are two different ways how we are building
> external modules today:
>
> (1) after the kernel source tree was just compiled, so the kernel
> source tree still contains all the object files,
>
> (2) in a separate step, against an almost clean kernel source tree.
> Almost-clean means the tree contains a set of configuration files,
> and the modversions dump file.
>
> The modversions dump file elegantly solves both cases.
You already convinced me about the usefullness of the modversions file.
Can you try to make a patch that _only_ incorporate the modversions
functionality. This we could ask Andrew to apply when reviewed.
See it as first step.
Then I will try to work out something for the functionality outlined
before.
> > Agree - should be easy to test using a CD.
> > Are there an easy way to mount just a directory structure RO?
>
> Not sure what you mean exactly. My main motivation is this: we have a
> whole bunch of external modules that we build one after the other. Those
> external modules are notoriously nasty: We had cases where the modules
> fondled in kernel headers in the original tree. Of course then the next
> modules would build against a broken tree. To stop and detect such
> madness, I want to give modules a kernel source tree to which they have
> no write access, by chowning to a different user. Trees on read-only
> media are irrelevant IMHO.
Actually we agree, I just did not think of chowing the files/dirs to
catch the problems.
Sam
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
