[PATCHv2 3/4] staging: android: ion: Add an ioctl for ABI checking

Laura Abbott labbott at redhat.com
Fri Sep 2 20:26:31 UTC 2016


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


More information about the devel mailing list