* Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
> On Mon, 25 Jan 2010, Steven Rostedt wrote:
>
> > On Mon, 2010-01-25 at 10:12 -0800, Linus Torvalds wrote:
> >
> > > But on the whole, I think it's actually worked out pretty well for them.
> > > I think the mainline kernel has improved in the process, but I also
> > > suspect that _their_ RT patches have also improved thanks to having to
> > > make the work more palatable to people like me who don't care all that
> > > deeply about their particular flavor of crazy.
> >
> > Actually this is an understatement. Every feature (and I do mean _every_)
> > that went from -rt into mainline, undertook 3 or more rewrites before it
> > was acceptable for mainline. And every time, the end result made the -rt
> > patch set better as a whole.
> >
> > Not to mention, that a lot of the early stuff also cleaned up mainline.
> > You can't have Real-Time without having a clean kernel. And as you stated,
> > a lot of those patches to clean up the kernel, no one even knew that the
> > real reason was to help the -rt patch set. They were well disguised Trojan
> > horses.
>
> Tsss. Never admit such things.
Here's four examples of recent kernel features:
- lockdep [1]
- ftrace [2]
- new-style generic mutexes and spin-mutexes [3]
- the new arch/x86 tree [4]
I suspect few would guess that all of these features were motivated by the -rt
kernel originally:
[1] lockdep started out as the 'track irqs-off sections' patches in -rt
[2] ftrace started out as -rt's latency tracer and logdev
[3] mutex.c was motivated by rtmutex.c
[4] arch-x86 was motivated by annoyance with needless porting of -rt
features from 32-bit to 64-bit x86 and back.
[ Nor would you normally guess that Linux itself was motivated by a guy
wanting to toy around with 32-bit x86 assembly ;-) ]
Various forms of craziness that motivate us dont really hurt, as long as the
process is rooted in reality. We can 'wish' for the crazier future stuff and
can help it indirectly, and sometimes it might even happen down the road - but
reality and common-sense utility is what controls.
And note that there's nothing dishonest about doing multi-purpose patches, as
long as the mainstream purpose isnt really just a decoy. When we decouple a
feature from -rt we usually forget its -rt purpose and the intermediate
for-mainstream forms arent even useful for -rt - back-integration into -rt
comes at a later stage. This makes it doubly sure that it's all formed by
mainstream's need, not -rt's needs.
In the few cases where the -rt role is prominent for some weird reason we
declare it as such. It's the exception to the rule really - few useful kernel
features are single purpose. ( When they are then we are likely doing
something wrong. -rt _is_ a special case. )
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
