3 ms·
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
by peterwwillis 10y ago
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.
- SEJeff 10y agoYou 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?
- PaXTeam 10y agocareful there, the author line doesn't imply authorship (if it does, the upstream kernel is already violating our copyrights).