On Wed, 26 Sep 2018 at 17:41, Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > On Wed, Sep 26, 2018 at 4:02 PM Ard Biesheuvel > <ard.biesheuvel@xxxxxxxxxx> 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.
