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

[tlaronde%kergis.com@localhost]

On Sat, Nov 04, 2023 at 08:20:43AM +0000, Michael van Elst wrote:
> tlaronde%kergis.com@localhost writes:
> 
> >disable {drmkms}	# NEW: disable devices belonging to group "drmkms"
> 
> Almost noone would need to turn off all drmkms drivers. What you may
> want to control is that a GPU isn't used as a console. Disabling a driver
> is just our crude workaround to achieve this.

The problem is, at the moment, that we can not separate the GPU
handling from the drmkms stuff, meaning that one can not modify "at
run time" because, in some cases, one never gets to "run time": it
crashes.

The drmkms code (drm2/) has increased the size of the kernel sources
by... 50% (!). A "correct" solution can not be found now by diving in
the drmkms code.

So the crude workaround has to be achieved in a simpler way than
listing all the drmkms related drivers: a user trying GENERIC
does not necessarily know what is present on his hardware and does not
have to find what particular drivers he has to disable/enable.

> 
> I don't think that autoconf is the right place for such a control,
> it should be a boot parameter, maybe even something that can be
> changed at runtime later.
> 
> The current system of boot parameters is limited and differs a lot
> between platforms. We need a common way to set boot parameters and
> these should be mostly defined in a platform-agnostic way.
> 

For the moment, putting definition of groups in config(1) and handling
in userconf, achieves this goal of arch independence.

And since the problems with drmkms are mainly for x86 machines, there
is for x86 boot.cfg in which by default we could disable drmkms and
simply instruct user to enable it (try once) at userconf console with
"enable {drmkms}" and, if this works, to comment out the
"disable {drmkms}" in boot.cfg.

> 
> >Hint: Linuces distributions "work" as proposed images on servers,
> >where NetBSD fails.
> 
> Servers usually do no have drmkms capable hardware, and if they have,
> you probably want to use that hardware.

Been there and seen this (I mean: didn't see anything...): to use the
hardware, you have to know it is here; when drmkms makes the kernel
crash, on a remote node without remote boot administration/console,
you will never know what it has and you will think that NetBSD
simply doesn't work...

So, disabling drmkms to verify that NetBSD works without it allows
you to know what the hardware is and, after that, you can try
to enable drmkms at least knowing that if it crashes (if you don't have
access anymore...), this does not mean that NetBSD can not drive it,
simply that this has to be without drmkms (we need to have a boot once
feature too so that if a remote node crashes, rebooting restore a
working boot sequence).
-- 
        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