Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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.migeon%free.fr@localhost


Home | Main Index | Thread Index | Old Index