linux-kernel - Re: [PATCH anybus v3 0/6] Support HMS Profinet Card over Anybus

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]

Message-ID: <CAK8P3a1STE+vN_yF0Zyu8gGX_KCWZEV=muPxVE6M1EUqdhO4Pg@mail.gmail.com>
Date:   Fri, 9 Nov 2018 22:22:04 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Sven Van Asbroeck <thesven73@...il.com>
Cc:     svendev@...x.com, Rob Herring <robh@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        DTML <devicetree@...r.kernel.org>
Subject: Re: [PATCH anybus v3 0/6] Support HMS Profinet Card over Anybus

On Fri, Nov 9, 2018 at 5:02 PM Sven Van Asbroeck <thesven73@...il.com> wrote:
>
> Arnd, Rob, Linus,
>
> Many thanks for your constructive feedback so far !
>
> Is there anything in general about this set that would prevent it from being
> mainlined? Perhaps I am trying to do too much at once, dropping a patchset
> that is too complex to be properly reviewed?

As usual, it comes down to the user space interfaces I think. Designing
a user interface is hard, most importantly because you cannot change it
once anyone starts relying on it, as opposed to implementation details
that you are free to change at any point.

It's also hard to find reviewers for it, the best you can hope for
is that you find people that have both knowledge about the type of
hardware you work with and Linux user interface design, and
get them to review the code.

> I've been thinking about reworking the host to its simplest, yet feature-
> complete form. Just serialize all card accesses with a single lock.
> Then the kernel thread, kqueue, kcache, kref etc would all disappear.
> The price we pay is a reduction in performance/parallelism.
> We could then increase parallelism at a later stage.
> Would that be of any help?

I don't think that's a major issue. If you are happy with the
implementation there, and you use the interfaces correctly, that
won't stop the driver from getting merged, even if you could
rework it to use something else later.

      Arnd