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
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
