In article <4e7e14f0.2050...@msys.ch>, Marc Balmer  <m...@msys.ch> wrote:
>On 09/23/11 12:38, Marc Balmer wrote:
>> With gpio(4) we still carry an old API with us, which I want to
>remove.  While working on it, I will also introduce a third locator to
>device drivers that attach to gpio pins, flags.  It will be needed for
>e.g. gpioiic(4) to invert the SDA/SCL pin numbers.
>>
>> WIll documenting the changes be enough?
>
>I want to make it clear that this will change the binary ABI and break 
>backwards compatability:
>
>*** Please note that gpio(4) is not enabled in GENERIC kernels by 
>default, so users of GENERIC or MONOLITHIC kernels are not affected by 
>this change. ***
>
>- the old and deprecated API, which is not documented and not used by 
>our own tools, will be removed
>
>- one current ioctl, GPIOATTACH, will be changed, as a third locator 
>will be introduced for flags (this is needed e.g. to reverse the pin 
>ordering of SDA and SCL pins in gpioiic(4))
>
>- maybe I will just rearrange all ioctls.
>
>The consequences are:
>
>- if you use an older gpioctl(8) it will not work with gpio(4) anymore. 
>  You need to rebuild gpioctl(8)
>
>- if you have your own software that talks to gpio(4) (and that excludes 
>drivers), you will have to recompile them.

I vote to do it without keeping backwards compatibility. The impact is
really limited to worth the trouble and the kernel bloat.

christos

Reply via email to