[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/sys/arch/amd64/conf
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:
> 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 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
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.
Main Index |
Thread Index |