The future of realtime Linux

Posted Nov 7, 2013 9:18 UTC (Thu) by dlang (guest, #313)
In reply to: The future of realtime Linux by karim
Parent article: The future of realtime Linux

if it can't be maintained and collapses, it won't be serving it's users.

a lot of the core kernel folks have been doing this for a long while, they have learned things that you just don't get until you have been maintaining and improving the same thing for several generations. When you start looking at something and can't say "what was the idiot who wrote this thinking" because _you_ were that idiot, and you remember exactly what you were thinking, it starts to change how you approach new things. You become a bit more discriminating about what you implement and you think a lot more about the effort to maintain things. In the short term, you slow down, but by reducing the long-term maintenance burden you actually end up going faster over time.

and while it's hard to tell users 'no' or 'not now' or 'fix it first', many projects who don't push back end up collapsing and burning out and providing nothing to their users.

(Log in to post comments)

The future of realtime Linux

Posted Nov 7, 2013 9:52 UTC (Thu) by karim (subscriber, #114) [Link]

I get all of that. But none of those arguments make any sense if the thing has been *actively* maintained for 10+ years.

The future of realtime Linux

Posted Nov 8, 2013 6:57 UTC (Fri) by dlang (guest, #313) [Link]

and I'll throw back that if it's no problem to maintain, they can continue to maintain it out of the kernel for another 10+ years

but the reality is that it is a problem to maintain it separately, merging it with the mainstream kernel greatly reduces the work for those people who have been maintaining it so far, but that work doesn't all just go away, it goes out to the other kernel maintainers who now have to make sure that new changes don't break -rt, and they have to respond when the -rt people try to block other "important" features going in.

so it makes sense for the kernel maintainers to be careful about major changes.

The future of realtime Linux

Posted Nov 11, 2013 8:47 UTC (Mon) by karim (subscriber, #114) [Link]

I'm sorry, I must be confused. Why does the externally-maintained codebase all of a sudden stop being the responsibility of the external maintainers? In what ways are they less capable of maintaining their code in tree than they were out of tree? Why would they stop being capable of resolving the issues they had been resolving to smooth their code to continue working as a patch onto mainline once they actually become part of the official codebase?

Initially I said: "I'd like to think mainline's purpose is to serve its users, not its own self. But I do tend to be idealistic." If indeed the kernel's purpose is to serve its users then there would be some recognition that those needing real-time actually do need real-time in the kernel. What we have now is people maintaining functionality that was aimed back in 2005 at providing hard real-time and that currently actually doesn't and might actual never do so. How that becomes the benchmark for admitting something that actually solved that same problem even before PREEMPT_RT came around is beyond my clearly limited intelligence.

The future of realtime Linux

Posted Nov 11, 2013 9:47 UTC (Mon) by dlang (guest, #313) [Link]

> Why does the externally-maintained codebase all of a sudden stop being the responsibility of the external maintainers?

well, if the external maintainers are saying that they will be finished with it within a year by either getting it merged upstream or they will stop maintaining it, they must believe that getting it merged will result in others doing some of the work that they have been doing.

The future of realtime Linux

Posted Nov 11, 2013 14:53 UTC (Mon) by raven667 (subscriber, #5198) [Link]

Well also, in the general case, once code is accepted into mainline then it's ultimately Linus responsibility and the subsystem coordinators for maintenance, they can't just point fingers if something needs to be fixed and the original developers aren't available for any reason, they are on the spot to fix it themselves which is why they've become conservative when it comes to big patch sets.

The future of realtime Linux

Posted Nov 12, 2013 2:41 UTC (Tue) by nevets (subscriber, #11875) [Link]

It's not that we'll stop maintaining it after it goes into mainline, but our work does become easier. Once it goes into mainline, than when another subsystem breaks PREEMPT_RT, we can ask that subsystem to do things differently to fix it. All kernel maintainers try not to break things that have been merged.

Currently, if a subsystem breaks PREEMPT_RT, we need to figure out a work around for that breakage. Sometimes we send patches to upstream, and they get fixed. Other times, it requires a bit of design change that upstream doesn't care about and that work goes into the -rt patch. Now the -rt maintainers need to maintain every subsystem in the kernel that breaks PREEMPT_RT, and that just does not scale.

Thus the comment about it either going into mainline or we are done is not saying we are done if it goes into mainline. But our work will be a lot easier if it is, as we don't need to maintain the entire kernel for PREEMPT_RT anymore. We just need to educate other maintainers on how to play nice with PREEMPT_RT.