Re: GENERIC and INSTALL kernels

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

On 12.02.2011 03:49, Izumi Tsutsui wrote:
> jeanyves.migeon wrote:
> 
>> IMHO, the real question is whether we should have a
>> self-sufficient GENERIC kernel for _booting_ a minimum system, or
>> not.
> 
> There are two points:
> 
> (1) Benefits of module(7) system
> 
> The reason of using module(7) is flexible configuration without
> recompiling a kernel. Most NetBSD geeks always have whole source tree
> in their machines and they can build their own kernels in a few
> minutes, but most ordinary users won't bother to fetch whole large
> sources to enable/disable just one feature.
> 
> module(7) allows users to choose necessary functionarity and I see
> several users who say kernel modules are useful on other OSes.
> 
> If you don't think module(7) has any benefit as some other
> developers, this discussion is over.

Not at all. I am just concerned by a GENERIC kernel that can bring the
system in a non-easily recoverable state if it fails getting modules,
and there are multiple situations where this can happen: failed update,
buggy PXE or network, missing files in an NFS share, etc.

Frankly, it seems safer to have a kernel that, at least, can boot safely
up to single user, instead of successively failing when mounting ffs by
returning EFTYPE or execing init with ENOEXEC, and ends up in ddb. Now,
try guessing why it fails mounting root or execing init(8)...

> (2) Definition of "GENERIC"
> 
> If you think GENERIC should also be applicable to RAMDISK based 
> INSTALL kernel, it should be MONOLITHIC.
> 
> If you think GENERIC should be "self-sufficient," (I'm not sure what
> it means but I guess no dependency on external file systems?) it
> should be MONOLITHIC.

self-sufficient => can boot up to a point where we have acceptable
access to tools so we can fix the system. Up to single user seems
reasonable.

> If GENERIC is considered to be used with a prepared root file
> system, it can be MODULAR and can provide flexible configurations to
> users.
> I don't think GENERIC should have common configuration with
> INSTALL kernels.

They have to share as much code as possible; GENERIC is probably the
kernel that will be the most widely tested, including on recent
hardware. The more we deviate from it, the more we risk of proposing a
non-working INSTALL kernel. INSTALL_FLOPPY, for example, did not have
acpi support compiled in.

>> Current NetBSD bootloader is capable of loading modules on-demand,
>> but we are not forcing everyone to use NetBSD's bootloader (some
>> may want to use Grub, Grub2, uboot, whatever).
> 
> Again, bootloader support is necessary only for modules required to
> mount root file system, i.e. typically FFS or NFS. All other modules
> can be loaded by a _kernel_ if all *.kmod files are prepared in the
> root file system.
>
> I agree that GENERIC should contain at least FFS and NFS, but
> bootloader doesn't affect EXEC_FOO or TMPFS/MFS etc.

That's indeed a separate issue.

So, we at least agree that we have to "builtin" certain file-systems in
GENERIC if we want to be able to mount / without relying on the
bootloader to pre-load certain modules for us (as we cannot force
bootloader's choice -- Grub won't automagically load modules, for
example). FFS and NFS are good candidates.

cd9660 is not a problem, it is mainly used in conjunction with the
cd9660 bootloader for boot CDs, so it will preload cd9660.kmod anyway.


Now, why do you think it isn't sane to "builtin" a minimal set of
modules that could allow GENERIC to boot safely up to single user? I am
not sure that ending up in a ddb prompt just because someone forgot to
install the new modules set provides... flexibility. And arguably, it is
not really convenient to fix things from a ddb prompt + combined reboot
with an old kernel (if you have acces to one!), rather than trying to
save things from a single user shell.

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