Re: kern/41668 (MONOLITHIC should probably also be included in HEAD builds)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

The following reply was made to PR kern/41668; it has been noted by GNATS.

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/41668 (MONOLITHIC should probably also be included in HEAD
 builds)
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:
 
 http://mail-index.netbsd.org/current-users/2009/12/21/msg011759.html
 
 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
 first test-boot.
 
 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
 configuration file)?
 
 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?
 
 Thanks,
 -- 
 Matt