Re: GENERIC and INSTALL kernels

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

On 12.02.2011 05:26, Izumi Tsutsui wrote:
>> 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,
> 
> Why should the GENERIC be so? Why not RESCUE kernel like /rescue?

It doesn't cost much to have a minimal set of modules builtin GENERIC
instead of a having an additional rescue kernel which will basically
be... a MONOLITHIC kernel (e.g. GENERIC with MODULAR turned off :o )

>> and there are multiple situations where this can happen: failed update,
> 
> Is there any difference between failures on updating kernel and
> updating modules?

Well yes, somewhat: updating kernel was regularly shown as a one file
substitution; with compat magic, you could still replace an old kernel
with a new kernel and boot with the old system without trouble.

Game is different with modules though: they are easily missed with the
method above, and, well, if you replaced /netbsd bluntly without
installing modules... ouch. You end up within ddb with non trivial
errors, and without a chance to quickly launch a few commands to fix the
system.

>> 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.
> 
> Why should GENERIC be self-sufficient?

See above. IMHO, it should be resilient to mistakes like this one.

It only requires EXEC_ELF32/64 and EXEC_SCRIPT. I thought init(8) had to
play magic with /dev on MFS for console, but it does not. So, better
leave TMPFS/MFS out.

I am still unsure about CD9660 though. Having the possibility to mount
an ISO might be a plus.

>> They have to share as much code as possible;
> 
> Possible, but not necessary.
> No problem to have different config for different purpose.

Except that you have to maintain them :)

>> GENERIC is probably the
>> kernel that will be the most widely tested, including on recent
>> hardware.
> 
> BTW, if module(7) is in GENERIC, it will be tested as well.
> 
> Anyway I doubt most NetBSD geeks who claim MODULAR is not necessary
> are using GENERIC binaries ;-p

I'm probably not clear, so sorry to repeat myself: I am not in favor of
removing modular, I just want to see ELF and SCRIPT support as builtin
in GENERIC.

I really can't see what it brings to modularize those, given their
omnipresent need today (I am not even sure that you could modunload(8)
them without risk). Frankly, is there any system out there, except those
run by der Mouse, that do not need ELF and SCRIPT support?

> INSTALL kernel should be different from GENERIC.
> What's the problem using MONOLITHIC for INSTALL and leave GENERIC as is?

Well, given the work put inside modular support, why not use it?

With correct integration, I can retire MONOLITHIC, and just build an
INSTALL kernel from a GENERIC one with just a few tweaks to embed the
ramdisk inside, containing modules.

Nothing impossible, amd64 does that already, except that its GENERIC
integrates most of its modules as builtin (which defeats the purpose of
modular, BTW).

> Is it really more worth to make GENERIC monolithic to share it
> with INSTALL kernel than providing module(7) functions by default?

I do _not_ want to turn GENERIC into monolithic.

>> 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?
> 
> Builtin modules cannot be disabled or replaced without sources.
> Consider pros and cons. If you don't think module(7) is useful,
> I have no more comments.

Oh, god. I am not saying that module(7) is not useful, I just want to
have a _very_ _small_ _minority_ of them builtin as default, as there's
no reason to provide them as external modules. Namely, EXEC_ELF and
EXEC_SCRIPT.

>> I am
>> not sure that ending up in a ddb prompt just because someone forgot to
>> install the new modules set provides... flexibility.
> 
> Just document "don't forget to install modules as well as kernel."
> 
> Anyway, module(7) is required for users who won't compile their kernels,
> i.e. users who are using installers and release distribution binaries,
> so you don't have to worry about failure on updating.
> 
> If everyone thinks NetBSD is an OS for (stupid) geeks, I'll shut up.

From a different point of view: I just see NetBSD as an OS that wants to
stay robust.

And no need to shut up, you have the right to express your opinion.

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