Re: [gentoo-dev] [LAST CHANCE]: kernel + kernel module ebuild changes

[Peter Johanson]

On Thu, Mar 18, 2004 at 09:37:52AM +0900, Georgi Georgiev wrote:
> maillog: 17/03/2004-18:55:05(-0500): Peter Johanson types
> > On Thu, Mar 18, 2004 at 08:47:30AM +0900, Georgi Georgiev wrote:
> > > maillog: 16/03/2004-10:00:45(-0500): Peter Johanson types
> > > > 3) config-kernel - A new tool for manipulating a few things relating to
> > > > your kernel environment. It is purely meant to affect the way your
> > > > kernels live on your system, and NOT for generating kernels, etc.
> > > > Features include:
> > > >   - setting a prefix for kernel output (e.g. a new kernel
> > > >     2.6.4-mm1 will have it's output set to
> > > >     /var/tmp/kernel-output/2.6.4-mm1). Users can choose a new prefix, or
> > > >     disable using koutput using config-kernel.
> > >
> > > How exactly is this going to be implemented? Is the tool going to write to a
> > > config file or create a symlink /usr/src/linux-output for example? Don't forget
> >
> > All variables that affect things are going into /etc/env.d/05kernel
> >
> >
> > > that the user would have to still be able to easily compile a kernel on their
> > > own using the methods they are used to, i.e. make config, make menuconfig, make
> >
> > They *will*. Things will be mostly transparent to the user. When a new
> > kernel is installed, or if a user does "config-kernel --make-koutput
> > /usr/src/linux-2.6.4" the toplevel makefile is edited to add the line
> > KBUILD_OUTPUT=/var/tmp/kernel-output/$KV
>
> So, this one variable does not go into /etc/env.d/05kernel? In fact, if the
> variable is set in the environment, there is no need to set it in the makefile
> as well, right? The environment would override it anyway.

No, a variable KBUILD_OUTPUT_PREFIX is set, which kernel-2.eclass will
use to determine what gets added to the makefile at installation time.
The reason for this is we don't want KBUILD_OUTPUT set globally, as this
would screw up having 2.6.3 and 2.6.4 both compile (they'd put things in
the same spot, etc, etc). This is why we have to set it for each kernel. 

>
> > By adding this variable, when someone does:
> > # make menuconfig
> > in that source tree, all the output files end up wherever KBUILD_OUTPUT
> > points to. that's all it takes. You can run all the normal make commands
> > as normal, but things end up elsewhere. No nasty hacking. The below
> > stuff is unnessecary.
> >
> > When users want to override the output, *then* they can specify things
> > on the command line. A normal user wanting to build a kernel for some
> > Alpha box they have can do the following:
> > $ mkdir ~/kernel-output/2.6.4-alpha
> > $ cd /usr/src/linux-2.6.4
> > $ make ARCH=alpha O=~/kernel-output/2.6.4-alpha menuconfig
> > $ make ARCH=alpha O=~/kernel-output/2.6.4-alpha
> >
> > And they've then built a kernel for an alpha (assuming they have the
> > toolchain in their PATH, etc, etc) against the sources they had no write
> > access to.
> >
> > This make sense?
>
> Sure does.
>
> The reason for the nasty hacking is because I wanted to be able to easily
> rebuild different versions (EXTRAVERSION-s) of a kernel using the same source.
> Setting KBUILD_OUTPUT only sounds as if someone could easily screw up. I mean,
> the user would have to run config-kernel *and* edit the version in the Makefile
> in the original source every time. I think this step could easily be moved to
> config-kernel.
>
> For example, config-kernel could derive the version from the output directory
> name (if we agree to a naming convention), and edit the versions in the
> Makefile every time.  Or it could require more parameters on the command line?
> Or it could support optional parameters, and only when they are provided, it
> could edit the Makefile. It would also have to create a file in the output
> directory, so the next time, when a user switches back to a previously used
> KBUILD_OUTPUT directory, the old version is restored automatically. In fact,
> config-kernel could directly create the first five lines in
> $KBUILD_OUTPUT/Makefile if the file is not already there, and simply restore
> the lines if the file is available.
>
> I used too many words, but my point was that kernel version and output
> directory have to be consistent between switches.
>

Yeah, It hadn't occured to me to try to incorporate more than one
EXTRAVERSION compile with this system. Doing things like this would get
really complicated/messy, but this might be mitigated by making:
KBUILD_OUTPUT= $KBUILD_OUTPUT_PREFIX/$MAJOR.$MINOR.$PATCHLEVEL$EXTRAVERSION
So that this happens automagically. whenever you change EXTRAVERSION in
the toplevel makefile. Only problem with that is the destination
directory isn't guaranteed to exist if you do this. config-kernel could
be extended to add a --set-extraversion foo which could handle all those
particulars though. WOuld this be sufficient?

-pete

> --
> ()   Georgi Georgiev   () Break into jail and claim police brutality.  ()
> ()    chutz@×××.net    ()                                              ()
> ()  [phone]   ()                                              ()



-- 
Peter Johanson
<latexer@g.o>

Key ID = 0x6EFA3917
Key fingerprint = A90A 2518 57B1 9D20 9B71  A2FF 8649 439B 6EFA 3917