[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/41668 (MONOLITHIC should probably also be included in HEAD builds)
The following reply was made to PR kern/41668; it has been noted by GNATS.
From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
Subject: Re: kern/41668 (MONOLITHIC should probably also be included in HEAD
Date: Tue, 26 Jan 2010 18:51:14 -0500
On Tue, 26 Jan 2010 13:15:04 +0000 (UTC)
Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
> Yes, definitely - what's more, aside from some build time consumed in
> making an extra kernel, I cannot even imagine how having MONOLITITHIC
> as well as a (modular) GENERIC can possibly harm anyone - all that does
> is give users an easy choice of which kernel they prefer, and how that
> can possibly be considered as "confusing the needs of the producers with
> the needs of the consumers" is beyond my comprehension.
I agree here, but could perhaps be biased as I tend to also build my
own NetBSD releases (and packages repository). Although I'm also a
programmer, I'm not a registered NetBSD developper, however, so I
consider myself an advanced user. I might assume that most users have
the same needs as mine, or use NetBSD the same way. Also, we're pretty
far away from a desktop-ready Ubuntu-like system, so I assume that
NetBSD users expect something different.
> Note: I totally support having modules as part of NetBSD, and in being able
> to build and run modular kernels - there's no question that there is a
> community for whom that's the best way to operate. And with that, I also
> support having the GENERIC kernel being a modular kernel in current - since
> the modular system is new, that's the best way to cause it to be used, so
> the problems can be found and corrected. So, I'd do the above mv's on the
> netbsd_6 branch after it is created - before 6.0 alpha releases start being
> created, ie: first thing after the branch is created - either that or on
> current just before the branch, then undo it again on current (6.99.*)
> immediately after the branch.
I'm not against modules either, but I feel that something is missing to
be using them in the current state of things. Another interesting
related thread, to which I also participated should be linked here:
One important problem for me is that although it's way easy to compile
and install a new monolithic kernel, this is more troublesome with
modules. If advanced users think that way, how about novice users when
having to deal with the modular system?
build.sh (and the build system) probably should be updated with a new
target to build a modular kernel image along with its modules together
in a pack (i.e. perhaps a directory named GENERIC containing both an
image and the hierarchy of corresponding kernel modules)?
As it now is, modules seem to be built and installed as part of
userland, in a fixed location. This makes testing or upgrading a new
kernel troublesome, unless it's monolithic. And yes, users do need to
occasionally test a -current kernel, or to first test-boot a new kernel
when upgrading their system before upgrading userland.
With kernel modules at a fixed location and a modular kernel, to
upgrade a system, one would have to move the old modules away, install
the ones from the new userland build, install the new kernel image,
update the boot code, boot it and test it, to then install the rest of
userland if all seems fine, and then deal with etcupdate/postinstall as
necessary. With a monolithic system, userland doesn't need to be built
first (perhaps the tools only) and there's no problem mixing
image/modules together, or even upgrading the boot code before the
Couldn't it be as simple for modular with a sound hierarchy? Other
than the boot code having to also be updated more often than before
because of fs modules needing to be loaded, of course.
An example of another modular system is Linux, where modules are built
and installed as part of the kernel build scripts, in a directory which
name includes the kernel version. Since NetBSD is not only a kernel,
perhaps we could use the custom kernel name (i.e. the name of the
Another option would be to guarantee binary compatibility of modules
and for new kernels to continue to support old modules, but that is
probably absurd (it makes sense for OS userland compatibility only IMO).
Or are NetBSD "end users" supposed to never test new kernels or upgrade
their systems, and we should make this as hard as possible?
Main Index |
Thread Index |