Re: [RFC 2] userconf(4): 2nd proposal

[tlaronde%kergis.com@localhost]

On Sat, Nov 04, 2023 at 11:59:00AM +0100, Martin Husemann wrote:
> On Sat, Nov 04, 2023 at 11:25:01AM +0100, tlaronde%kergis.com@localhost wrote:
> > I think that my second proposal is the simplest, allowing not breaking
> > existing and introducing extensions without much typing.
> 
> This whole thing still makes no sense to me. You can do what you want
> with userconf already and this is not a common operation so any simplification
> for something that only makes sense (1) for ad hoc testing or (2) encoded
> in boot.cfg does not gain us anything for real.
> 
> For the real world issue at hand (bugs in kernel drivers that claim the
> console but then do not work) either a boot flag (like RB_MD4 on x86)
> or what you call "ad hoc mechanism" makes a lot more sense to me.

An "ad hoc mechanism" would be to construct a list of drivers to
disable them in block i.e. exactly the same as what can be done
already with userconf if you know the drivers names. The only
advantage of this ad hoc solution would be to require only a
generic instruction instead of several commands to disable all or the
necessity to know exactly which one to disable. This is what my
proposal is about, but instead of polluting the sources with an
"ad hoc" solution, by adding a feature that can be of some more
general use in other cases, for debugging or disabling a collection of
devices (group).

So how can you discard my proposal as "no sense", when your ad hoc
solution is only a variation around the same thing?

Secondly, a more fine grained solution to disable a portion of the
drivers dealing with the console is more involved---because if it was
not, it would have already been done, no?

And this is the problem: the drm2/ source is 206 MB (!!!). Our drmkms
sources are already not in sync with the Linux ones (I'm watching
them and there have been already major changes, for i915 and
particularily for amdgpu). So the NetBSD turtle may beat the Linux
hare, but in the end; certainly not in a speed race...

And there is the NetBSD 10 release. A definitive or even only correct
solution will not be found if 10 has to be released soon.

I'm just proposing something simple enough to improve the "crude
solution"---on par with the Linux/GRUB feature. That's the best that
can be done for the time being due to the size (that's the word...) of
the problem...
-- 
        Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C