On 09/01/2016 11:10 PM, Greg Kroah-Hartman wrote:
On Thu, Sep 01, 2016 at 03:40:43PM -0700, Laura Abbott wrote:
The current Ion ioctls lack a good way to tell what ioctls are available. Introduce an ioctl to give an ABI version. This way when the ABI inevitably gets screwed up userspace will have a way to tell what version of the screw up is available.
This worries me. Why do we need this? Shouldn't any "new" abi changes just add on, and not change existing ioctl structure calls? Or worst case, you remove an ioctl and then userspace "knows" that when the call fails.
This may be more of an "I wish we had this when some poor decisions were made in the past". There were a couple of instances when the Ion ABI was broken (adding new fields, new ioctl numbers) that were a nightmare to deal with and a similar ioctl would have helped a lot. The botching-ioctls document also made reference to something simliar.
And who is the major userspace user of this interface? Who controls it? How are we keeping things in sync here?
I would expect this to not actually be used until we have breakage. The broken ioctl would then be checked as needed.
Reading all this and thinking some, it sounds like this shouldn't actually be needed so long as we continue to not break the ioctls. I had a thought of this possibly making life easier for out of tree users to eventually convert over but I haven't heard much from actual out of tree users.
I'd like to keep it just to hedge my bets but I also haven't had as much experience maintaining stable ioctls for the long term. If, from others experience, this type of ioctl is actually just more prone to breakage and doesn't help then I don't want to push something that will eventually break.
thanks,
greg k-h
Thanks, Laura