Date: Sat, 16 Dec 2000 09:20:46 -0800 (PST)
From: ferret@phonewave.net
To: Miquel van Smoorenburg <miquels@traveler.cistron-office.nl>
cc: linux-kernel@vger.kernel.org
Subject: Re: Linus's include file strategy redux
In-Reply-To: <91fiht$7ve$1@enterprise.cistron.net>
Message-ID: <Pine.LNX.3.96.1001216084813.22767C-100000@tarot.mentasm.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org


On 16 Dec 2000, Miquel van Smoorenburg wrote:

> In article <Pine.LNX.3.96.1001215194935.19208D-100000@tarot.mentasm.org>,
>  <ferret@phonewave.net> wrote:
> >On 15 Dec 2000, Miquel van Smoorenburg wrote:
> >
> >> I think /lib/modules/`uname -r`/ should contain a script that
> >> reproduces the CFLAGS used to compile the kernel.
> >
> >However it happens, the necessary information THAT I KNOW OF is:
> >0) The kernel headers under linux/include
> >1) The state information generated by running make configure ; make dep ;
> >make clean -OR- equivalently by Debian's make-kpkg clean ; make-kpkg
> >configure which does the same thing but adds packaging-specific metadata.
> 
> That state info is in ARCH, CFLAGS, CC and include/linux/autoconf.h

Ah, thank you for resolving the state information for me. =)

> >A SYMLINK from /lib/modules/`uname -r`/ into /path/to/kernel-`uname -r`
> >will not always work, because:
> >0) The destination may not even exist (if the kernel has been installed
> >onto another machine)
> 
> Yes but in that case, how are you going to compile a module without
> the kernel headers anyway. If you compiled a kernel on one
> machine and you know that you want to be able to compile modules
> on the second machine you need to copy over /usr/src/linux-x.y.z/include
> as well.

My point was that this symlink makes an assumption that is not always
valid. And assuming things that are not always valid (opposing to things
that do not always exist) is generally Wrong.

> >1) The destination has no metadata or has the WRONG metadata (if I've just
> >compiled and installed 2.4.0-test11 on my i386, then am now building same
> >for my sun4c)
> 
> As I said the kconfig script should do some simple sanity checks-
> compare version and architecture at least.
> 
> >I have been recently told that a full copy of kernel headers and metadata
> >in /lib/modules/`uname -r`/ isn't going to work either, but the gentleman
> >who informed me of this hasn't yet shown why.
> 
> Because lots of use have a small root file system of just 30 MB ?

Yes, yes. Very good point. So (as I was thinking this morning as I awoke)
the symlink could stay, IF it could be guarenteed not to be dangling on
the target machine. I suspect making the symlink should therefore be left
to the administrator or local package manager.

We still can say that IF the symlink exists and is not dangling, that
third-party modules source MAY ASSUME it points to headers configured for
the running kernel. But the kernel build process SHOULD NOT make the
symlink.

> Hmm, but as soon as you start thinking about cross-compiles etc
> you need more and more state - like CROSS_COMPILE, AS, LD, CPP, AR,
> NM etc etc. Yuck. It would probably be better to put all that info
> in /usr/src/linux/Config.make, and use the current "build" symlink.
> A module makefile would then look like this:
> 
> #! /usr/bin/make -f
> 
> # You might want to point BUILD somewhere else.
> BUILD = /lib/modules/$(shell uname -r)/build
> include $(BUILD)/Config.make
> 
> module.o:
> 	$(CC) $(CFLAGS) -c module.c
> 
> Ah yes, this is probably a much better approach then a kconfig script

s/better/simpler/

A kconfig script will of course need to override BUILD in certain cases,
but with make this is trivial.

This solves one specific outstanding issue, and IMO at first glance before
my first cup of coffee should solve it well. But a kconfig script is meant
to do many other things as well. Some of these other things are big enough
to be held until 2.5.0, and are mentioned in another post.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/