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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 15 Nov 2018 07:11:09 -0800
From:   Arnd Bergmann <arnd@...db.de>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     Boris Brezillon <boris.brezillon@...tlin.com>,
        Vitor Soares <vitor.soares@...opsys.com>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        Jonathan Corbet <corbet@....net>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        gregkh <gregkh@...uxfoundation.org>,
        Przemyslaw Sroka <psroka@...ence.com>,
        Arkadiusz Golec <agolec@...ence.com>,
        Alan Douglas <adouglas@...ence.com>,
        Bartosz Folta <bfolta@...ence.com>,
        Damian Kos <dkos@...ence.com>,
        Alicja Jurasik-Urbaniak <alicja@...ence.com>,
        Cyprian Wronka <cwronka@...ence.com>,
        Suresh Punnoose <sureshp@...ence.com>,
        Rafal Ciepiela <rafalc@...ence.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Nishanth Menon <nm@...com>, Rob Herring <robh+dt@...nel.org>,
        Pawel Moll <pawel.moll@....com>,
        Mark Rutland <mark.rutland@....com>,
        Ian Campbell <ijc+devicetree@...lion.org.uk>,
        Kumar Gala <galak@...eaurora.org>,
        DTML <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Xiang Lin <Xiang.Lin@...aptics.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Sekhar Nori <nsekhar@...com>,
        Przemyslaw Gaj <pgaj@...ence.com>,
        Peter Rosin <peda@...ntia.se>,
        Mike Shettel <mshettel@...eaurora.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH v10 0/9] Add the I3C subsystem

On Thu, Nov 15, 2018 at 7:01 AM Wolfram Sang <wsa@...-dreams.de> wrote:
> > What we could do though, is expose I3C devices that do not have a
> > driver in kernel space, like spidev does.
>
> ...
>
> > Mark, Wolfram, Arnd, Greg, any opinion?
>
> Is there a benefit for having drivers in userspace? My gut feeling is to
> encourage people to write kernel drivers. If this is, for some reason,
> not possible for some driver, then we have a use case at hand to test
> the then-to-be-developed userspace interface against. Until then, I
> personally wouldn't waste effort on designing it without a user in
> sight.
>
> Dunno if you have that, but a debug interface (exchanging data with
> clients) on the other hand would be super useful most probably. Maybe
> you can start having that in debugfs and already learn from it if you
> ever want to move some interface outside of debugfs?

I think it may depend a little bit on the complexity we require
for a user interface. If it's basically just pread/pwrite, then the
debugfs would not look any different from a stable interface,
and there is little risk of getting it wrong. The more complex
the interface turns out to be, the more cautious we may want
to be about declaring it stable.

Other than that, I agree we should encourage users to write kernel
drivers, but given the precedent of uio, libusb, spidev, i2c-dev,
and vfio, it does seem extremely likely that users will have
requirements for it, and I think it's a good idea to start the design
discussion before users start building their own interfaces to do the
same thing badly.

        Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ