On Friday, February 10th, 2023 at 10:37, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Thu, 09 Feb 2023 17:03:19 +0000 > Simon Ser cont...@emersion.fr wrote: > > > On Thursday, February 9th, 2023 at 17:38, Joshua Ashton jos...@froggi.es > > wrote: > > > > > > I mean, the strings are the uAPI, not the integers, right? > > > > > > Both are uAPI these days. > > > > Yes. The integers are uAPI, if you change them you'll break libliftoff > > users. There is an old thread discussing this somewhere. The tl;dr was > > that there is no use-case for exposing the same string with a different > > integer, so no good reason to justify the substantial complexity of > > handling this case. > > Funny, I remember exactly the opposite. There was a bacxk-and-forth on this topic. > This case would have been multiple different strings with the same > integer, anyway. That would be fine. As long as the meaning of an integer doesn't change across planes, it's all fine. > But no matter. If a uAPI header or documentation has exposed the > integers, then there is no taking that back. uAPI headers/docs don't expose the integers for this property. Nevertheless, one cannot break user-space. > This won't be a problem for enums that have no meaningful string names, > like enums where the integer names a blob that describes what the value > means, and enums where the integer is an index into an array of > descriptions exposed as a blob. This would be pretty tricky to handle.
