On Sat, Feb 19, 2011 at 11:33:08AM +0200, Adam Hamsik wrote:
> > Are you going to add a MONOLITHIC kernel to match i386?
>
> I object against such change so I hope that we are not going to
> repeat such move.
I object to *not* having a standard MONOLITHIC config for the
following reasons:
1. Traditionally, whether a driver/fs/option/whatever is listed in
GENERIC is an indicator of how stable it's believed to be: entities
that are missing are assumed not to work at all, entities that are
commented out are assumed not to be stable, and only entities that are
included and enabled by default are assumed to be production-ready.
This is a longstanding convention and it's wired into the built-in
operating assumptions of many experienced sysadmins. There is now no
way to tell which of the commented out entities are stable but meant
to be used as modules and which of them are unstable/experimental or
otherwise not ready yet. Having the stable drivers and other entities
be present and uncommented in MONOLITHIC is not a good solution but
it's the best currently available. (To solve this problem properly the
config file syntax needs to be extended.)
2. While not removing FFS and ELF support from GENERIC is a start, few
of the other robustness concerns that have been brought up over the
last two years have been addressed properly.
- End users who are trying to diagnose a driver problem still
will not be able to test -current by downloading and booting a
kernel. They will need to also download and install a module
set. This vastly increases the overhead and complexity of trying
out -current and puts it past the reach of many newbies. This is
a serious problem.
- There is still no way to avoid building modules you don't want,
and while we have a start on a method to prevent autoloading
them, it's not ready for prime time yet. Therefore, the only safe
way to disable any functionality that's available as a module is
to turn off "options MODULAR". This requires either expert
attention or a maintained MONOLITHIC config.
- The versioning of installed modules is still restricted to one
set per sys/param.h kernel version, and there's no way to tie a
particular set of modules and a particular kernel together. This
means that anyone working on broad kernel changes that affect
module ABIs (e.g. me, but I'm hardly the only one) must in
practice stick to monolithic configurations -- if any
adjustment I make affects a module ABI I need to do a private
sys/param.h bump and do a nearly full rebuild, instead of
recompiling half a dozen files actually affected by the change.
This is a non-starter; furthermore, in such an environment if I
screw up with the versions I can easily render my test machine
unbootable.
These issues have all been brought up repeatedly over the past two
years without being solved. In fact, in general all such discussions
have been shouted down by module advocates insisting without evidence
that no such problems exist -- this is why these problems remain
unsolved and have been mostly receiving no further attention, and why
a large fraction of i386 developers simply use MONOLITHIC.
There is therefore no reason to think that any of these issues will be
resolved rapidly. The project needs to be able to continue to move
forward on other things until they are.
Please at least set up a MONOLITHIC config. I would prefer, however,
if, instead, GENERIC was left as a monolithic config and a MODULAR
config was made available for testing. Committing GENERIC to be
modular can and should wait until the serious issues have been sorted
out and the module system is ready for production use.
(I also question whether saving 1/16 of 0.1% of the typical RAM of a
not particularly beefy amd64 system is worth the complications of
dealing with modules.)
--
David A. Holland
dholl...@netbsd.org
