[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4C600F37-33E3-4C3D-B7D1-BBB85D5A2195@goldelico.com>
Date: Fri, 10 May 2019 12:06:03 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Bastien Nocera <hadess@...ess.net>
Cc: Jonathan Cameron <jic23@...nel.org>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Eric Piel <eric.piel@...mplin-utc.net>,
linux-input@...r.kernel.org, letux-kernel@...nphoenux.org,
kernel@...a-handheld.com, Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Peter Meerwald-Stadler <pmeerw@...erw.net>,
linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org
Subject: Re: [RFC v2] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface
> Am 10.05.2019 um 11:35 schrieb Bastien Nocera <hadess@...ess.net>:
>
> On Fri, 2019-05-10 at 11:33 +0200, H. Nikolaus Schaller wrote:
>>>
> <snip>
>> It does through "Input device name:" starting with "iio-bridge:" as
>> you can see in the commit message of [RFC v3]:
>
> This makes it ABI, right?
The "Input device name:" is already ABI of the input system (although I guess the string is
built into the evtest tool). I think there are also /sys nodes which carry the same information.
But yes, if someone changes the "iio-bridge:" prefix in kernel code it breaks a user space lib
making use of it:
+ poll_dev->input->name = kasprintf(GFP_KERNEL, "iio-bridge: %s",
+ indio_dev->name);
+ poll_dev->input->phys = kasprintf(GFP_KERNEL, "iio:device%d",
+ indio_dev->id);
This type of exporting names seems to be quite common. E.g. "mmcblk0p1" which may end up
in some /etc/fstab.
>
> Big fat warnings around the code that declares it would be appreciated.
Ok.
Powered by blists - more mailing lists