> Date: Sun, 11 May 2025 06:39:42 -0700 (PDT) > From: Paul Goyette <p...@whooppee.com> > > On Sun, 11 May 2025, Greg Troxel wrote: > > > Thus I suspect I am missing something. > > Yup, I think you're missing the fact that all of this relates to the > ratther new-ish KERNEL_DIR option, support for which was only recently > completed (by myself). KERNEL_DIR is described briefly in options(4), > and it is noted in both CHANGES and UPDATING. > > In short, KERNEL_DIR provides a mechanism to keep a kernel and its > associated modules together, addressing one of the most common > complaints about modules. > > Sorry for not making this more clear.
I think it is important to (a) make this clear and obvious and intuitive, _and_ (b) make sure we have tested any plausible transition paths that might happen. To that end, this present proposal aside (I haven't digested it, no comments about it), I would strongly suggest that you make a wiki page describing everything about the KERNEL_DIR changes (not just the terse summary in CHANGES, or the notes in UPDATING which are only for an audience of current users to maintain MKUPDATE=yes builds), including a systematic table of: 1. What has changed or will change in the standard bootloader? 2. What has changed or will change in a custom bootloader with any new build options? 3. What has changed or will change in an unmodified GENERIC kernel? 4. What has changed or will change in a custom kernel with any new build options? 5. What does/will sysinst do? 6. How are transitions/upgrades expected to happen? What will happen when a stock netbsd-10 installation is updated to a stock netbsd-11 installation? 7. How have all of these scenarios been tested? We really need to make sure this doesn't become another /var/db/pkg renaming debacle that leaves everyone's machines in confusing inconsistent states requiring manual intervention. This type of change -- substantially altering the semantics of how the bootloader finds the kernel -- has an extremely high risk, not just of putting machines into confusing states, but of rendering them unbootable when you update the bootloader. And, if we were doing it again, I would ask that any changes be proposed to tech-kern and port-*, with all this relevant information, _before_ committing anything that affects default builds. (It's likely that there already are good answers to all of these questions, and you've already figured all this out -- it's just not clear to me from the CHANGES and UPDATING notes and the scattering of commit messages I've seen fly by, so I'm just asking for a clear picture to be presented in an obvious place to see how this will affect users.)
