On 10/09, Måns Rullgård wrote: > Stephen Boyd <sboyd@xxxxxxxxxxxxxx> writes: > > > On 10/09, Rob Herring wrote: > >> > >> Adding a ptr to the callback seems fine to me. > >> > > > > Does that mean a flag day? Urgh. Pain. I'm not opposed to adding > > a pointer, in fact it might be better for performance so that we > > don't take a cache miss in read() functions that need to load > > some pointer. We were talking about that problem a few months > > ago, but nothing came of it. > > Flag day in what sense? There aren't all that many users of the > interface (56, to be precise), and sched_clock_register() isn't > exported. That's exactly what a flag day is. Lots of coordination, lots of acks, etc. Last time when I changed the registration API I made a new registration API, moved every caller over one by one, and then deleted the old registration API. That's how you manage a flag day. We could probably do the same thing again with two different types of registration APIs so that we move over users one by one. The old registration API would be wrapped with a sched_clock local function that doesn't pass the pointer it gets called with, while the new registration API would fill in the function pointer that we call directly from the core code. The double function call is probably bad for performance, so I guess we should get rid of it and always pass the pointer to the callback. But this is at least a method to convert everything gradually without breaking users that may be going through different trees. > Verifying the change will be a minor pain, but I don't see > why it should have any major consequences. Obviously I'd just set the > pointer to null for existing users and leave it for the respective > maintainers to make proper use of it where sensible. > Sure. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
