Re: DRM-KMS: add a devclass DV_DRMKMS and allow userconf to deal with classes

[tlaronde%kergis.com@localhost]

On Thu, Oct 19, 2023 at 09:10:36AM -0400, Mouse wrote:
> > I propose to add a DV_DRMKMS class to sys/device.h:enum_devclass; to
> > augment cfdata with a devclass member [...]
> 
> > Comments?
> 
> This is not intended as criticism; I am just trying to examine all
> sides of this question.
> 
> Why use the sys/sys/device.h kind of device class for userconf?  Is
> there some reason to think it will be useful to userconf other device
> classes, or do you expect other device-class machinery to have a use
> for DV_DRMKMS, or is it a question of just reusing the existing device
> class rather than creating a new kind of device class, or what?

I'm just trying to stay in the vincinity of cfdata, for the headers and
for the benefit (consummation) of config(1) uphill and userconf
downhill.

For the moment, the drivers are given the DV_DULL class, while for
modules several classes are given. But userconf doesn't deal with
modules...

The other reason is that with the drmkms multiple modules classes are
provided. It seems to me that, even if it would be useful to disable
specific childs (if only for debugging purposes), at the moment there
should be a "main" class to disable everything uphill.

So the DV_DRMKMS is not exactly the "drmkms" class of modules...

> 
> I'm also thinking it could be useful for a device to fall into multiple
> classes for userconf, but I _think_ DV_* classes don't support a device
> being in multiple classes.

Yes: the DV_* are exclusive: a device can not appear in several classes.
This is emphasized in the man page and in the source.

>  It also could be useful for custom kernels
> to have custom modifications to device classification.  So I'm
> wondering if it would be better for this to be a namespace specific to
> config(1) and userconf rather than having anything to do with DV_*
> values.

This is precisely why I ask for comment ;-) I have two requirements: 

- that the solution is not ad hoc i.e. that it can provide, in userconf,
facilities not limited to drmkms (I don't want to implement a special
case to recognize "drmkms" and to expand to all the STARred driver names
implied);
- that it will not imply to have to maintain special data
for userconf to recognize some "magic" strings.

But the second item: generating data according to conf is the task of
config(1). So config(1) should do the job.

Indeed good question: devclass or modules classes or something else? The
usr.bin/config/TODO is already listing the problem of the two kind of
classes.
-- 
        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