On 19.02.2011 10:27, Bernd Ernesti wrote: > On Wed, Feb 16, 2011 at 03:16:58AM +0000, Jean-Yves Migeon wrote: >> Module Name: src >> Committed By: jym >> Date: Wed Feb 16 03:16:58 UTC 2011 >> >> Modified Files: >> src/sys/arch/amd64/conf: GENERIC INSTALL >> >> Log Message: >> Build certain file-systems and options(7) as module(7). 32 and 64 bits >> support are still builtin, as well as FFS, NFS, TMPFS, and most COMPAT >> code. Saves approx. 750kiB. >> >> Reflect this in INSTALL kernel, where we have to support more file systems >> statically. >> >> See http://mail-index.netbsd.org/port-amd64/2011/02/13/msg001318.html > > Are you going to add a MONOLITHIC kernel to match i386?
No. And honestly, I can't see why MONOLITHIC is needed in the first place: it was introduced as a quick fix for those that wanted to bluntly replace their old kernel with a new one, without risking crippling their system on reboot because ELF and FFS kmods were gone missing. I dare say that MONOLITHIC was a step in the wrong direction: instead of cutting down MODULAR options(4) from GENERIC, it would have been better to include everything as builtin modules, while still offering modular support. I can't see the difference of having MONOLITHIC instead of GENERIC with modules as builtins, except for cases where you want to block module loading, for security purposes. But there, you are better off removing most COMPAT code also, which means a new kernel build, anyway. I perfectly know that the question of "what should be in, and what should stay as a third party kmod?" is entirely debatable. I notified core@ about that, and wait for their answer. We could have the bare minimum builtin inside GENERIC, or provide most options(7) as kmods by default. -- Jean-Yves Migeon jeanyves.mig...@free.fr