lkml.org 
[lkml]   [2018]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations
    On Wed, 26 Sep 2018 at 17:41, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
    >
    > On Wed, Sep 26, 2018 at 4:02 PM Ard Biesheuvel
    > <ard.biesheuvel@linaro.org> wrote:
    > > I don't think it makes sense to keep
    > > it simple now and add the complexity later (and the same concern
    > > applies to async support btw).
    >
    > Ugh, no. I don't want to add needless complexity, period. Zinc is
    > synchronous, not asynchronous. It provides software implementations.
    > That's what it does. While many of your reviews have been useful, many
    > of your comments indicate some desire to change and mold the purpose
    > and focus of Zinc away from Zinc's intents. Stop that. It's not going
    > to become a bloated mess of "things Ard wanted and quipped about on
    > LKML." Things like these only serve to filibuster the patchset
    > indefinitely. But maybe that's what you'd like all along? Hard to
    > tell, honestly. So, no, sorry, Zinc isn't gaining an async interface
    > right now.

    Framing it as /needless/ complexity does not help at all. The changes
    you are proposing are very useful, but nobody wants two crypto
    subsystems with two different maintainers in the kernel, so I would
    like to understand where this is going in the future. I am not saying
    it should block these patches though.

    Also, I have spent a *lot* of time looking at your code, and trying to
    make it better, especially for use cases that weren't on your radar to
    begin with (e.g., 'pet projects' [your words] like the Cortex-A7 which
    will be in almost every new 32-bit Android phone). So characterizing
    my feedback as some kind of sabotage is not very productive either.

    Contrary to what you seem to think, I am not deeply invested in the
    crypto API. What I do care about is that the ARM crypto pieces in the
    kernel are maintained, supported and improved by someone who
    understands the use cases Linaro's members care about, and is willing
    to make an effort to gain such understanding if he doesn't. I have no
    doubt that your involvement in the kernel's crypto subsystem will have
    a significant positive impact when it comes to code quality,
    robustness and usability. I'd just like to see a bit more
    consideration for other aspects of kernel programming, e.g.,
    preemption under -rt, stack size constraints, coding style, importing
    code from other projects etc. - please try to be less dismissive of
    feedback first time around, but try to understand why people are
    raising these issues; I'm sure you will appreciate it when future
    contributors to zinc will do the same.

    \
     
     \ /
      Last update: 2018-09-26 18:55    [W:4.683 / U:0.592 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site