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.mig...@free.fr