from the let-the-feature-war-continue dept.
Deep in the mailing list for the device-mapper project is this email exchange, after a patch to bring a request-based dm-crypt implementation was shot down by maintainers, among them Christoph Hellwig: "NAK for more request based stacking or DM drivers. They are a major pain to deal with... No, you will NOT remove the bio based path. That would break all kinds of perfectly valid setups."
The argument in favor of request-based dm-crypt was to utilize hardware encryption engines, but this was deemed too flimsy an argument to risk ruining the rest of the users of device-mapper. But then, Mark Brown reveals that Qualcomm had already implemented an "out-of-tree implementation" of this in a Board Support Package: "Android now wants to encrypt phones and tablets by default, and have been seeing substantial performance hits as a result; we can try to get people to share performance data from productionish systems, but it might be difficult."
In response to that, notable block storage kernel developer Jens Axboe replied, "Well, shame on them for developing out-of-tree, looks like they are reaping all the benefits of that."
(Score: 2) by Nerdfest on Saturday November 14 2015, @03:01PM
Isn't that how open source is supposed to work, assuming the licence allows it?
(Score: 3, Informative) by Gravis on Saturday November 14 2015, @03:42PM
i have yet to see a license that says all branches must be accepted, so yes, that is exactly how it should work!
perhaps being vague with "that" wasn't a great idea.
(Score: 1) by Shimitar on Saturday November 14 2015, @04:12PM
It is, if they release the source code to any end user who request it. If this is not the case, then no it is not...
Coding is an art. No, java is not coding. Yes, i am biased, i know, sorry if this bothers you.
(Score: 2) by Nerdfest on Saturday November 14 2015, @04:15PM
Actually, even that depends on the licence.
(Score: 5, Informative) by PocketSizeSUn on Saturday November 14 2015, @05:09PM
Not sure what this is article is trolling for.
To Recap:
It looks like the first implementation (in the qualcomm tree) was originally done by Dinesh and now Baolin is trying to get it included in mainline, presumably with Dinesh's support, as Baolin is maintaining Dinesh's Signed off by, and Cc: dinesh but at a different domain -- assumption is that this is a valid address for Dinesh although including the sign-off email in the Cc or updating the sign-off is probably better, IMHO.
Christoph clearly is not in favor of the current state of request based DM and is not inclined on those grounds.
As far as Jens statement, the import part of that is a request for real numbers about performance breakdowns around measuring hardware encryption overhead with request to buffer size. Not that Jens is the only one asking ...
Right now it is a wait and see if Baolin can show believable numbers that justify feeding the encryption pipeline chunks larger that a bio based DM can supply.
I have looked at the code and if Baolin is correct and that feeding the crypto engine [ablkcipher_request_set_crypt()] with more pages per call then doing the same (trivial) thing in dm-crypt means transparently improving things for everyone.
So the overall justification for dm-req-crypt is very weak.
Note that Baolin said his hardware crypto has a 1M buffer.
If someone gets their hands on a crypto chip with a 16M buffer and shows that there is another significant jump using multi MB submissions over just 1MB submissions then the dm-req-crypt is worth looking into. I don't think it will be that big of a gain ... but it might be .. chip makers don't usually waste transistor counts on something they don't think customers want. If so, given this started in embedded media capture such as Video and Pictures is the usage pattern that would benefit first (or so I imagine).
(Score: 2) by Runaway1956 on Saturday November 14 2015, @05:15PM
Thank you, PSS. I read this while it was in the queue. Didn't make a lot of sense to me. Clicked the link, and it still didnt' make a lot sense. Your summary sorta makes it click together. So, thank you. Sorry, I've squandered all my mod points today.
(Score: 3, Disagree) by opinionated_science on Saturday November 14 2015, @05:09PM
I smell an attempt to engineer in a backdoor....either make a faster version and we all use it , or keep the code out of the base. Pretty much every phone made in the last decade has the maths capability for encryption baked in. And let's not forget the GPU's....