linux-kernel - Re: [Letux-kernel] [RFC v2] iio: input-bridge: optionally bridge iio acceleometers to create a /dev/input interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Sat, 8 Jun 2019 11:52:07 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     linux-input <linux-input@...r.kernel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Eric Piel <eric.piel@...mplin-utc.net>,
        linux-iio <linux-iio@...r.kernel.org>, kernel@...a-handheld.com,
        lkml <linux-kernel@...r.kernel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Hartmut Knaack <knaack.h@....de>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, Bastien Nocera <hadess@...ess.net>
Subject: Re: [Letux-kernel] [RFC v2] iio: input-bridge: optionally bridge
 iio acceleometers to create a /dev/input interface

On Mon, 3 Jun 2019 09:30:40 +0200
H. Nikolaus Schaller <hns@...delico.com> wrote:

> Hi Jonathan,
> sorry again for the long delay. I just now found a little time to summarize and try to
> get the discussion boiled down to the key difference.
> 
> > Am 11.05.2019 um 13:05 schrieb Jonathan Cameron <jic23@...nel.org>:
> > 
> > On Thu, 9 May 2019 19:02:49 +0200
> > "H. Nikolaus Schaller" <hns@...delico.com> wrote:
> >   
> >> 
> >> If you close the lid, the display is turned upside down and y and z axes reverse sign.
> >> 
> >> So there remains only the issue that user-space must know which sensor device file is which sensor
> >> and can do the calculation of the lid angle. This is possible because the iio accelerometer name
> >> is available through the input event ioctls.
> >> 
> >> In summary this case also does not need policy or configuration. Just user space using the information
> >> that is already presented.  
> > 
> > I disagree with that last statement.  If there is a lid angle sensor, policy is
> > needed to know which of your associated orientation is the base one and which
> > device indicates the lid angle.  
> 
> > 
> > Actually most of the time what you will do is pick one 'correct' sensor under
> > some configuration of the device and use that.  That is policy.  Yes, you could
> > bake the policy in to device tree, but then you can also bake in the association
> > between the underlying IIO sensor and any virtual input sensor.  
> 
> Ah, maybe I did not understand what you mean by policy here.
> 
> Indeed, choosing the right sensor is always something which is application specific
> and something user-space must obviously dictate. And we agree this should *not* be
> in device tree (or user-space scanning device tree) because that describes hardware
> and not user-space interaction.
> 
> But I still do not think that this requires a new mechanism where user-space
> *tells* the kernel which sensor to use and present as which device.
> 
> Equally well, the kernel can present all sensors it knows about and a set of properties
> that allow the user-space to simply choose the right one ("apply policy"). Properties
> could be file name (e.g. provided by udev), device name, label (provided by DT) or similar.
> 
> If it were absolutely necessary to tell the kernel to map iio devices to something before
> use, I think Bastien would not have been able to implement his library. He also has to
> choose the right sensors. This seems to work and not need a new mechanism.
> 
> > 
> > Anyhow, we still disagree on whether any such virtual input interface
> > should be a userspace policy decision.  So far I haven't seen any compelling
> > argument why it shouldn't be and the flexibility such a policy based interface
> > provides is its major advantage.  
> 
> I still think it is not needed because kernel already provides necessary information
> to user-space to make policy decisions (by ignore unwanted interfaces) without needing
> a new interface where the user-space tells the kernel to activate some interfaces.
> 
> So the key difference is about the question if user-space needs to tell the kernel first
> that it wants to see a specific interface or just makes use of it if present.

Absolutely. Good summary, but I don't think either of us is going
to persuade the other.

I've started work on my proposal but things have been 'interesting' in the
last few weeks so it may be a little while yet before I have anything
to share.

Jonathan

> 
> BR and thanks,
> Nikolaus
>