DragonFlyBSD

I tend to like the variable name to begin with K... or KERN..., if
they are related to kernel, to avoid name clash with some other
applications (note that environment variables can also affect make
variables). You may(or may not) feel this way when you a description
in bsd.own.mk.

DESTDIR is `An existing directory to be the root of the hierarchy'
according to build(7), and the location of kernel/modules in the hierarchy
has been moved from / to /boot. For instance, when you build an ISO image
from the source, DESTDIR is set to ISOROOT, but kernel and modules should be
installed under ISOROOT/boot, not right under ISOROOT. So if you do want
to be able to install the kernel/modules to some other directory not
containing .../boot, I think you can introduce a variable, say KERNDIR,
which defaults to /boot.

make installkernel KERNCONF=MYSMPCONF POSTFIX=.smp KERNDIR=/

or, with traditional method:
cd /sys/config
config -d /path/to/builddir /path/to/MYSMPCONF
make depend && make
make POSTFIX=.smp KERNDIR=/ install

Cheers.

Hmm. Maybe we should call it KLABEL instead of POSTFIX.

: make installkernel KERNCONF=MYSMPCONF POSTFIX=.smp KERNDIR=/
:

KERNDIR is a bit confusing.  Maybe BOOTDIR to override the default
    'boot', or something like that.

-Matt

What's the use of this except saving a few keystrokes? We have
DESTKERNNAME for setting the kernel's name and in my opinion that's
quite enough.

Just my 2c,
Sascha

New try. How about DESTKERNDIR (to go with DESTKERNNAME) and KERNPOSTFIX?

DESTKERNNAME only affects the name of the kernel and if you have
different module options between different kernel configs you want to
have something in common between the kernel name and the modules
directory name -> KERNPOSTFIX.

DESTKERNDIR is a added directive and does not interfer with DESTDIR.

--

Mvh  - Stefan -

For example, if you want to switch between UP and SMP kernels, you also
have to change UP and SMP modules, because not all SMP modules work
correctly with an UP kernel, or vise versa. POSTFIX also changes the
name of modules directory to modules.smp. If you want to keep kernels
with or without APIC option and share the same modules directory, then
DESTKERNNAME is what you want and you don't want to keep two modules
directories.

Small change regarding how the kernel directory is passed to the modules
make environment. DESTDIR is completely untouched now.

--

Mvh  - Stefan -

The problem I have is that having three different directives is, well,
it is rather confusing. I want to simplify it even more.

I have an idea.  Please tell me if this is way off base.

Why don't we just create a postfix out of the kernel name by default?
    So if you 'make installkernel KERNCONF=BLAH' you will get a
    /boot/kernel.BLAH and /boot/modules.BLAH ?

So, for example, a GENERIC kernel would be installed as
    /boot/kernel.GENERIC and /boot/modules.GENERIC.

We would then have a loader variable which defaults to 'GENERIC' in
    loader.conf, telling the loader which kernel to boot.

How does that sound?

-Matt

At a first thought it doesn't sound bad although I think it should still
provide a way to install a kernel under a different name without having
to change the kernel config's name.

Sascha

Install a kernel:
make installkernel KERNCONF=MYCONF

Install a second kernel, for example a SMP one:
make installkernel KERNCONF=MYSMPCONF KERNPOSTFIX=.smp

Install a kernel and modules somewhere else than /boot (like a VKERNEL):
make -DNO_MODULES installkernel KERNCONF=VKERNEL
DESTKERNDIR=/var/vkernel/boot

I put the examples here to show that it does not really get that
confusing. At least I don't think so and it gives all the options one
might want.
On the other hand I like the idea of making it even more simple. If
KERNPOSTFIX is not defined by the user we could set it to .${KERNCONF}
and we get the behaviour suggested above.

--

Mvh  - Stefan -

:Install a kernel:
:make installkernel KERNCONF=MYCONF
:
:Install a second kernel, for example a SMP one:
:make installkernel KERNCONF=MYSMPCONF KERNPOSTFIX=.smp
:
:Install a kernel and modules somewhere else than /boot (like a VKERNEL):
:make DNO_MODULES installkernel KERNCONF=VKERNEL
:DESTKERNDIR=/var/vkernel/boot
:
:I put the examples here to show that it does not really get that
:confusing. At least I don't think so and it gives all the options one
:might want.
:On the other hand I like the idea of making it even more simple. If
:KERNPOSTFIX is not defined by the user we could set it to .${KERNCONF}
:and we get the behaviour suggested above.
:
:-
:
: Mvh - Stefan -

Lets clean up the names a bit.  DESTKERNDIR is ok, but KERNPOSTFIX
    is a problem.  Lets rename KERNPOSTFIX to DESTVARIATION or DESTLABEL.
    I think DESTLABEL fits better.  KERNPOSTFIX is too confusing.

I've thought about it a bit more and I am going to back away from
    wanting the postfix automatically based on the kernconf.  But we
    do want to get rid of the '.' in the postfix (as well as rename it).

So how about this:

make installkernel KERNCONF=GENERIC

Installs as /boot/kernel, /boot/modules

make installkernel KERNCONF=FUBAR DESTLABEL=smp

Installs as /boot/kernel.smp, /boot/modules.smp

make installkernel KERNCONF=FUBAR DESTLABEL=smp DESTDIR=/mnt

Installs as /mnt/boot/kernel.smp, /mnt/boot/modules.smp

make installkenrel KERNCONF=FUBAR DESTKERNDIR=/mnt/fubar

Installs as /mnt/fubar/kernel and /mnt/fubar/kernel.smp

I think its important for DESTLABEL to not need the '.', though it
    does mean some additional complication in the Makefile's.  I recommend
    building an internal DESTKERNNAME and DESTMODULESNAME based on
    DESTLABEL.  If DESTLABEL does not exist DESTKERNNAME would be 'kernel'
    and DESTMODULESNAME would be 'modules'.  If DESTLABEL does exist then
    DESTKERNNAME would be 'kernel.${DESTLABEL}' and DESTMODULESNAME would
    be 'modules.${DESTLABEL}'.

One could also override the whole name by specifying DESTKERNNAME and
    DESTMODULESNAME.

How does that sound?

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

: make installkenrel KERNCONF=FUBAR DESTKERNDIR=/mnt/fubar
:
: Installs as /mnt/fubar/kernel and /mnt/fubar/kernel.smp

Oops, I meant /mnt/fubar/kernel and /mnt/fubar/modules for this
    example.

-Matt

DESTMODULESNAME is functionally similar to KMODDIR. Unfortunately the
default value of KMODDIR is defined in bsd.own.mk and only used by
kmod.mk and not by kern.post.mk. So, currently, if you set KMODDIR to
somewhere other than /boot/modules, modules-install still populates
/boot/modules.old with stripped version of modules in /boot/modules,
not with the ones in $KMODDIR.
The reason kern.post.mk does not care about the default value of KMODDIR
is because the Makefile in kernel build directory does not include
bsd.own.mk, which defines KMODDIR. I have no idea that bsd.own.mk should
not be included by bsd.post.mk or the Makefile in the kernel build directory.

Cheers.

Sounds fine to me. Attaching the latest diffs.

--

Mvh  - Stefan -

:> One could also override the whole name by specifying DESTKERNNAME and
:> DESTMODULESNAME.
:>
:> How does that sound?
:>
:> Matt
:Sounds fine to me. Attaching the latest diffs.
:
:-
:
: Mvh - Stefan -

Ok, I think this is a good commit candidate.  Get your last comments
    in now, I'm going to commit it tomorrow (Thursday) afternoon!

-Matt

Matt promised to commit it but hasn't. Is there a problem?

Hmm, I have been using those patches here ever since. That and me being
somewhat busy for almost 2 months made me totally miss it was not committed.

--

Mvh  - Stefan -

Hi, I've reworked the patch a bit to fix a few minor nits, including
breaking installation from an indivisual module directory (e.g.
`cd /sys/dev/netif/re && make -n install' would install to /).
I think that the check in kernel-installable target
(!defined(DESTKERNDIR) || ${DESTKERNDIR} == /boot)
is overkill; just setting DESTDIR to elsewhere can avoid overwriting
the real kernel installation, so you wouldn't do so with a variable with
longer name. If fact, we can set the default DESTDIR for vkernel to
/var/vkernel and we can save some keystrokes.

Please review/test attached patches and/or tell me if you like one or
both of them.

Cheers.

I only briefly looked over them. They seem good to me, please commit.

cheers
simon

Committed with modification.