KMS enums and bitfields UAPI

Daniel Stone daniel at fooishbar.org
Tue Apr 7 08:18:48 UTC 2020


Hi,

On Fri, 3 Apr 2020 at 13:24, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri, 03 Apr 2020 10:15:21 +0000 Simon Ser <contact at emersion.fr> wrote:
> > At the very least, having a clear policy for both kernel public headers and
> > user-space would help a lot. Right now it's unclear for both parties what to do
> > regarding enum values.
> >
> > What do you think?
>
> I do not think it is unclear at all. You have to query the kernel for
> value by string names. Maybe it's not clearly communicated though?
>
> But I also don't have anything against changing that policy, if kernel
> maintainers agree.

I'm in the same boat. The existing policy (runtime enum name lookups
are the only correct thing, and the presence of anything else in
headers is merely accidental) seems pretty clear to me. But I'd be
totally fine with changing it too, though it might require a cap to
say that this kernel version lets you use the stable integer
enumerations, and anything else requires runtime lookup.

I had a quick look to see how drivers used properties, and was
pleasantly surprised to see that only the (very old) Intel driver,
VMware and QXL drivers have custom properties. So maybe we don't have
to really worry about vendor-extended properties too much ... though
someone will definitely try to use it on some kind of nightmare vendor
BSP and have to fork libliftoff for it at some point.

Cheers,
Daniel


More information about the dri-devel mailing list