Re: linux-next: add utrace tree

[Ingo Molnar <mingo@elte.hu>]

* Thomas Gleixner <tglx@linutronix.de> 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