3 ms·

> That being said, if a group took it upon themselves to be a general-purpose "refactoring" team, ... I pretty much agree with you, but I'm not sure if it real

> That being said, if a group took it upon themselves to be a general-purpose "refactoring" team, ... I pretty much agree with you, but I'm not sure if it really needs a special cleanup task force. Stuff is being refactored and cleaned up on subsystem level all the time already. If, for instance, you do a `git log fs/squashfs` (an example I picked because I'm somewhat familiar with it, and there is comparatively little feature development) and skip past the maintenance fixes, there are a bunch of refactoring patches where common filesystem or block layer code was changed. On the mailing lists I'm on I somewhat regularly see Christoph Hellwig submitting larger cleanup patch sets for block layer stuff (even when you don't count the big cleanup spree during the first 2020 lock down). In the MTD subsystem there was a multi-year effort (earliest discussion with Boris and Miguel about this that I remember right now was around 2016) to refactor the entire subsystem, pull out a generic NAND framework, etc... But those are just some of the instances I can think off of the top of my head, from subsystems I'm personally somewhat familiar with. Regarding the ASN.1 parsers, Linux does have a `lib/` directory with common algorithms and helper functions in it. In fact one of the parsers being linked to is from there (https://git.zx2c4.com/linux/tree/lib/asn1_decoder.c https://git.zx2c4.com/linux/tree/lib/asn1_decoder.c). Somebody(TM) would "simply"(TM) have to patch the code in $SUBSYSTEM to use that instead, delete the old one and submit a patch set to the appropriate mailing lists. Of course it's a lot easier and less risky to simply post a mocking tweet and walk away. EDIT: In fact, this has already been done for one of them: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cc2d58634e0f489d28b5564c05abc69930b4d920 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

JackC 6y ago
> Of course it's a lot easier and less risky to simply post a mocking tweet and walk away. This tweet seems to be from Jason Donenfeld, who worked for years to refactor linux kernel crypto APIs as part of upstreaming wireguard, apparently with some success. (Random link for some context, though I haven't followed the whole arc of that story: https://www.phoronix.com/scan.php?page=news_item&px=Crypto-API-Doing-Some-Zinc https://www.phoronix.com/scan.php?page=news_item&px=Crypto-A... ) If you're aware of that context and think that Donenfeld is too critical of the kernel and hasn't done enough to fix it, then OK, but from an outside perspective it sure looks like he's put a ton of time into fixing things and earned some right to point out remaining issues.
- st_goliath 6y ago
  Thanks for the info! I only saw the twitter thread doing the usual point and laugh game and didn't bother looking further into at, given how often you stumble across those. Not being a Twitter user but tangentially following Wireguard development, the name Jason Donenfeld does ring a bell, in contrast to some Twitter account named "Edge Security". Interesting to know that the tweet from 2017 pointing out code duplication in the kernel is from the same person who, 1 year later, kicked off a brief flame war by wanting their own crypto library merged into the kernel alongside the existing one[1], before finally giving in and porting Wireguard to the existing API[2]. EDIT: Also thanks for pointing at the patch set for the crypto API. I have yet to look into that, as the last time I touched the kernel crypto API was a few years prior and I agree with some of Jasons criticism, although I can see the point of the kernel API being designed for asynchronous workloads, trying to explicitly support hardware accelerators, which I was also playing around with back then. [1] https://lore.kernel.org/lkml/CAKv+Gu9hOW0pOjDjrvg1q-v85aiwSZRnjivnvRTCwxMdph4j7g@mail.gmail.com/ https://lore.kernel.org/lkml/CAKv+Gu9hOW0pOjDjrvg1q-v85aiwSZ... [2] https://lists.zx2c4.com/pipermail/wireguard/2019-September/004560.html https://lists.zx2c4.com/pipermail/wireguard/2019-September/0...

JackC 6y ago

> Of course it's a lot easier and less risky to simply post a mocking tweet and walk away. This tweet seems to be from Jason Donenfeld, who worked for years to refactor linux kernel crypto APIs as part of upstreaming wireguard, apparently with some success. (Random link for some context, though I haven't followed the whole arc of that story: https://www.phoronix.com/scan.php?page=news_item&px=Crypto-API-Doing-Some-Zinc https://www.phoronix.com/scan.php?page=news_item&px=Crypto-A... ) If you're aware of that context and think that Donenfeld is too critical of the kernel and hasn't done enough to fix it, then OK, but from an outside perspective it sure looks like he's put a ton of time into fixing things and earned some right to point out remaining issues.

st_goliath 6y ago
Thanks for the info! I only saw the twitter thread doing the usual point and laugh game and didn't bother looking further into at, given how often you stumble across those. Not being a Twitter user but tangentially following Wireguard development, the name Jason Donenfeld does ring a bell, in contrast to some Twitter account named "Edge Security". Interesting to know that the tweet from 2017 pointing out code duplication in the kernel is from the same person who, 1 year later, kicked off a brief flame war by wanting their own crypto library merged into the kernel alongside the existing one[1], before finally giving in and porting Wireguard to the existing API[2]. EDIT: Also thanks for pointing at the patch set for the crypto API. I have yet to look into that, as the last time I touched the kernel crypto API was a few years prior and I agree with some of Jasons criticism, although I can see the point of the kernel API being designed for asynchronous workloads, trying to explicitly support hardware accelerators, which I was also playing around with back then. [1] https://lore.kernel.org/lkml/CAKv+Gu9hOW0pOjDjrvg1q-v85aiwSZRnjivnvRTCwxMdph4j7g@mail.gmail.com/ https://lore.kernel.org/lkml/CAKv+Gu9hOW0pOjDjrvg1q-v85aiwSZ... [2] https://lists.zx2c4.com/pipermail/wireguard/2019-September/004560.html https://lists.zx2c4.com/pipermail/wireguard/2019-September/0...