User: Password:
Subscribe / Log in / New account

Upstream first policy

Upstream first policy

Posted Jun 3, 2010 16:03 UTC (Thu) by fuhchee (guest, #40059)
In reply to: Upstream first policy by neilbrown
Parent article: A suspend blockers post-mortem

"We don't want the rival solution that works now, we want the rival solution that will still work in 5 years."

Considering how much of the kernel is regularly rewritten, deprecated, this policy appears to be selectively applied.

(Log in to post comments)

Upstream first policy

Posted Jun 3, 2010 17:14 UTC (Thu) by martinfick (subscriber, #4455) [Link]

Yes selectively, but the point you likely missed, is that it is with a strong focus on primarily maintaining the Kernel/Userspace API.

Upstream first policy

Posted Jun 3, 2010 18:24 UTC (Thu) by foom (subscriber, #14868) [Link]

Well, 5 years isn't actually that long. Most parts of the kernel userspace API that get deprecated and removed lasted far longer than 5 years in their previous incarnation. :)

Upstream first policy

Posted Jun 14, 2010 23:10 UTC (Mon) by aigarius (subscriber, #7329) [Link]

"Considering how much of the kernel is regularly rewritten ..."

That's actually the whole point - if what you have in the kernel is a custom-made ABI-locked solution that is distributed to millions of devices and can never-ever change, then there can be no rewrite full or partial and the kernel stagnates.

There are from time to time changes in the kernel that require kernel developers to change things around. And they need a freedom to do this. Now and in 5 years time. That is why they insist on keeping out things that they will not be able to change later on, including strict ABIs and narrow use cases in the generic parts of the code.

Google already got the benefit from this code being open so they could add this feature, but here the question is how to balance the maintenance burden of the feature on one hand with usefulness of this feature to other people. The suggestions in the LKML dealt with both sides - they reduced the maintenance burden by focusing the changes in less places and increased the usefulness of the feature, by making it more generic.

If before the discussion the usefulness of the code (to people outside Google) was less than the added maintenance burden it put on the kernel developers, then after the new proposal is implemented its usefulness just might be higher than the burden.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds