undefined | Better HN

0 pointspeterwwillis9y ago0 comments

He could have been working on it for 26 years and still failed to get it in, which would only mean that he sucks at it.

Other people have gotten large changes into the kernel before, but they require interfacing with the kernel devs and agreeing to certain changes first. Nobody's going to accept a patch just because Google wants it for one of its products. And Google isn't going to change its product patches just so they can fit in mainline.

0 comments

2 comments · 1 top-level

SEJeff9y ago· 1 in thread

You realize he is a core kernel dev, right? He's splitting into pieces one at a time. When a part of Linux sucks and your patch changes it, upstream has you change the part that sucks and then adapt your patch to it. Makes things often take longer than necessary for new contributors.

To give you an idea of Kees's contributions:

    ~/git/linux (master)$ git remote -v
    origin	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch)
    origin	git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push)
    ~/git/linux (master)$ git pull
    Already up-to-date.
    ~/git/linux (master)$ git log --author="Kees Cook" --pretty=oneline | wc -l
    701

Basically, he is getting as much of grsec as is feasibly upstreamable upstream as he's able to. Due to upstream Linux policies, the end results often turns out very different than the original grsec patches they were extracted from. Perhaps that is a better way of putting things?

PaXTeam9y ago

careful there, the author line doesn't imply authorship (if it does, the upstream kernel is already violating our copyrights).

j / k navigate · click thread line to collapse