On Thu, May 16, 2024 at 5:22 AM Maxime Ripard <mripard@xxxxxxxxxx> wrote: > On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote: > > I apologize as my worry is mostly born out of seeing vendors really > > push opaque feature flags in their old ion heaps, so in providing a > > flags argument, it was mostly intended as an escape hatch for > > obviously common attributes. So having the first be something that > > seems reasonable, but isn't actually that common makes me fret some. > > > > So again, not an objection, just something for folks to stew on to > > make sure this is really the right approach. > > I understand your hesitation and concern :) Is there anything we could > provide that would help moving the discussion forward? > Mostly I just want to make sure it's discussed, which is why I raise it as a concern. Getting APIs right is hard, and I know I've made my share of mistakes (for instance, a situation that very much echoes this current question: the *_ALARM clockids probably should have used a flag). So I've found highlighting the trade-offs and getting other folk's perspectives useful to avoid such issues. But I also don't intend to needlessly delay things. > > Another thing to discuss, that I didn't see in your mail: Do we have > > an open-source user of this new flag? > > Not at the moment. I guess it would be one of the things that would > reduce your concerns, but is it a requirement? So I'd defer to Sima on this. There have been a number of heap releated changes that have had to be held out of tree on this requirement, but I'm hoping recent efforts on upstream device support will eventually unblock those. thanks -john
