linux-kernel - Re: [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 PHC
Open Source and information security mailing list archives

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

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

Date:   Fri, 10 May 2019 10:57:22 +0200
From:   Bastien Nocera <hadess@...ess.net>
To:     Jonathan Cameron <jic23@...nel.org>,
        "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     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

On Mon, 2019-04-22 at 15:20 +0100, Jonathan Cameron wrote:
> > Different goals usually lead to different solution architectures.
> 
> Indeed, but in this case we have your proposal which is a subset of
> what
> I am suggesting.  One architecture can fulfil both requirements.
> 
> I'll leave it for the other thread, but Bastien has raised the case
> (that I'd forgotten) that there already userspace stacks that are
> capable of happily taking in both IIO and Input devices.  The
> confusion
> here is they will now discover 'both' without the existing userspace
> knowing that they are the same device.  We need to be very careful
> not
> to break those userspace programs.
> 
> So this is an illustration of why the simplistic case doesn't work
> 'now'.

I don't know what state the whole patch is, but, at the very least, I'd
expect that patch to export the fact that it's exporting synthesised
data from another driver, so that it can be easily ignored in user-
space that already supports IIO devices.