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 10:41:53AM -0400, Mouse wrote:
> >>> [...DV_DRMKMS...userconf...]
> >> [...devices in multiple classes...maybe use a separate namespace,
> >> used by only config(1) and userconf?...]
> > 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);
> 
> I agree with this; special-casing drmkms would be...suboptimal.
> 
> > - that it will not imply to have to maintain special data for
> > userconf to recognize some "magic" strings.
> 
> You already need that, in that userconf has to have some way to
> recognize the string "drmkms" as a device category (hinted by the
> "class =" syntax, but it still needs error-checking) and map it into
> the corresponding DV_ value.  I don't see it as significantly worse for
> config(1) to generate some data structure mapping device class names
> into whatever userconf would need to affect all devices of that class.
> 
> Though it occurs to me that there are too many things called "class"
> here.  "Group"?  "Category"?  "Collection"?

I concluded too that config(1) can do the generation of the tables during
the translation so there should not be a need to "manually" keep
up-to-date data files.

I think it would make sense to use "Group" and that this should be in
fact special to userconf: ability to handle, with userconf, a group of
devices, the list of groups being defined at config time, with some
USERCONF(USERCONF_GROUP_DRIVER, string) macro.

And adding the command in userconf to "set" a variable to a list, so
that for example: "disable name in $var" or "disable group in $var"
works (but for drmkms it will be defined at config time so this would
be: 'disable group = "drmkms"'.

This will allow customization both for a developper in source, and
for an end user to set, for userconf, a group of devices he wants to
enable or disable. (In this case, when the group is composed of devices
not mandatorily related in some way, "collection" would be a better
term than "group" (I'm with von Neumann when it comes to Set theory;
but let's not be pedantic).
-- 
        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