Re: CVS commit: src/sys/arch/amd64/conf

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 20.02.2011 22:58, David Holland wrote:
> 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.

How would you specify a module option considered production-ready (hint:
zfs)?

> 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.)

Hmm -- adding a comment telling that the feature is experimental?

What would it bring to extend config(5) to express such a feature?

> 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.

This is more a matter of giving appropriate sets, or
installation/release media, rather than being modular/monolithic.
Newbies do fine with Bubuntu/Linuxeries, and modules do live "happily"
there.

>    - 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.

Well, same goes for MONOLITHIC: turning off an option requires editing
config(5) file + kernel recompile. This requires "expert"
intervention... fetching src, building toolchain then kernel. Hum.

How is that less/more expert than playing rm(1) in /stand? That will
seriously block autoloading.

>    - 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.

100% agreed. Regular problem with Xen kernels.

> 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.)

Copy/pasting a mail I sent to Matthew:

----------------------------------------------------------------
[...]
Right; which one? i386. Curiously, I never heard of complains regarding
the amd64 one, which is MODULAR. Now why is that?

MONOLITHIC was added in a rush to shut up complaints, because people
couldn't make a difference between these types:
1 - MONOLITHIC kernel, where options are compiled in (_provided_ you
enabled them), with module support disabled
2 - MODULAR kernel, with most common options(7) compiled as "builtin"
modules (essentially making it like 1, except "options MODULAR")
3 - MODULAR kernel, with most options(7) compiled as third party modules.

Comparatively, the amd64 GENERIC never caused complaints, although it
uses modules: critical options(7), like FFS, EXEC_ELF32/64, COMPAT_32,
TMPFS/MFS were _builtin_.
----------------------------------------------------------------

Please stop opposing MONOLITHIC and MODULAR. Given the current
architecture, modules can be turned into builtins, which is, in essence,
the same thing as a monolithic kernel, when you turn on most options.

I also stated (also privately with Matthew) that "MONOLITHIC" was a bad
name. "NOMODULAR" would be more appropriate. If we enable most options
in GENERIC, MONOLITHIC would just be a "include <...>/GENERIC\n no
options MODULAR", with almost zero difference regarding code (well,
except that you won't have module support anymore).

So, one more time: the current issue is to define what people consider
as options that should be enabled by default, and what could stay out
(or as a third party module if you urgently need it back). One example:
accf_* is a questionable choice, whether its inside GENERIC (as a
builtin), or enabled by default in MONOLITHIC.

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost