Re: Module autounload proposal: opt-in, not opt-out

[Thomas Klausner <wiz%NetBSD.org@localhost>]

On Mon, Aug 08, 2022 at 07:18:05AM -0700, Paul Goyette wrote:
> It really seems to me that the current module sub-systems is at
> best a second-class capability.  I often get the feeling that
> others don't really care about modules, until it's the only way
> to provide something else (dtrace).

To reply to this point - I'm very interested in modules, but it
doesn't meet a basic requirement for me - easily going back to a
previous kernel when the new one is broken for some reason - if they
share the same kernel version, they share the same
/stand/amd64/9.99.99/modules directory, and if the problem is there,
I'm stuck.

Also, I'm not clear on what the new workflow is for my old one:

Update kernel:

A.
   build.sh kernel=NAME
   ln -f /netbsd /netbsd.old
   install ..../netbsd /netbsd
   reboot

B.
   build.sh what?
   ln -f /netbsd /netbsd.old
   ? something for old modules ?
   install .../netbsd /netbsd
   ? something for new modules, are they even built? ?
   reboot

If the kernel is broken somehow

A. drop to boot prompt
   boot /netbsd.old

B. drop to bootprompt
   ? What do I do to tell the old kernel where its old modules are ?
   boot /netbsd.old

I think /netbsd/ as a directory including a kernel and modules would
be a solution. I think christos? proposed it at some point and but it
never happened.
 Thomas