Upstream first policy [LWN.net]

Upstream first policy

Posted Jun 3, 2010 16:27 UTC (Thu) by bfields (subscriber, #19510)
In reply to: Upstream first policy by neilbrown
Parent article: A suspend blockers post-mortem

Developers focused on "make it work so we can ship" are going to be less focused on maintainability (or at least, that is the way it appears).

There can also be maintainability risks from designs that look elegant/highly general/whatever but that haven't been tested in the field.

I'm not really arguing one side or the other. In practice I think the really hard stuff is hard to get right without working on both tracks (thinking through the design carefully, and testing it in real situations) in parallel.

(Log in to post comments)

Upstream first policy

Posted Jun 4, 2010 3:41 UTC (Fri) by neilbrown (subscriber, #359) [Link]

Yes, nothing is really black-or-white is it?

I actually think there is a place for saying that a given interface is *not* permanent. That seems the be the main sticking point here.

If it were just code, we could import it, tidy it up, and be happy. Maybe it would change completely over a few release cycles. But as there is an interface involved that not everyone agrees with, we are stuck waiting for "perfect".

If we could say "This interface is only guaranteed to work with this library" or in some cases "... with this program", then I feel there would be a lot more room for flexibility. I have a vague feeling that ALSA works like this, but I'm not certain.

We have well-understood infrastructures for versioning libraries, breaking old API's, having multiple versions available and allowing old versions to be discarded selectively by distros. It would be great if the kernel interface could benefit the same way, and I think it should be possible to head that way.

Specifically, the nfsservctl syscall is probably totally unused these days, but it keeps a quantity of legacy code in the kernel which has to be maintained (though it is entirely possible that it is broken and nobody noticed).

Similarly the ioctls used for md/raid should go (though mdadm would need an update first - I haven't bothered because I "know" the ioctls have to stay) ... actually I now see that the sysfs interface I created to replace the ioctl interface is pretty horrible and really needs to be redone. If I could be sure that all users used mdadm ... or some library that I could create ... it would be a lot easier to deprecate old stuff.

Would that have helped with wakelocks? It is hard to be sure, but I think that it may well have done.