On Sat, Nov 04, 2023 at 08:20:43AM +0000, Michael van Elst wrote: > tlaro...@kergis.com 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