lkml.org 
[lkml]   [2011]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 09/11] sched: export task_prio to GPL modules
On Mon, Dec 05, 2011 at 03:17:49PM +0100, Ingo Molnar wrote:
>
> * Greg KH <greg@kroah.com> wrote:
>
> > On Fri, Dec 02, 2011 at 12:07:10AM +0100, Peter Zijlstra wrote:
> > > On Thu, 2011-12-01 at 14:14 -0800, Greg KH wrote:
> > > > greg k-h
> > >
> > > Greg, why are you merging this crap anyway? Aren't there enough tracer
> > > thingies around already?
> >
> > I don't know, is there?
> >
> > There's some reason the distros, and users, still use lttng,
> > so I'm guessing that it fits the needs of quite a few people.
>
> Same goes for a whole lot of other crap that distros are
> carrying. Would we want to merge a different CPU scheduler or
> the 4g:4g patch or a completely new networking stack into
> drivers/staging/? I don't think so.

Distros have new CPU schedulers and are still dragging the 4g split
around? A whole new networking stack would be interesting, and if
self-contained, possible :)

> I.e. putting LTTNG into drivers/staging/ will not really solve
> anything - and in may in fact delay any sane technical
> resolution:
>
> There's a difference between a driver that has to go into
> drivers/staging/ because nobody cares enough [and the driver
> isnt high quality enough yet], and a core kernel feature that we
> DO care about and which HAS BEEN REJECTED IN ITS FORM.

I didn't realize that lttng was rejected, when was that done? I
couldn't find it in the archives anywhere.

That's why I took this. It's a way for the code to get cleaned up, and
into "mergable" state, much easier, with more help than if it was
out-of-tree. The fact that distros have been shipping and relying on it
for years shows that it is something that is needed, and it being
self-contained, makes it eligible for the staging tree.

> > That's why I'm merging it, if that the in-kernel stuff
> > obsoletes lttng, great, let me, and the distros know.
>
> I'm NAK-ing the LTTNG driver really, as it's a workaround for a
> core kernel NAK.

Huh?

> Mathieu, please work with the tracing folks who DO care about
> this stuff. It's not like there's a lack of interest in this
> area, nor is there a lack of willingness to take patches. What
> there is a lack of is your willingness to actually work on
> getting something unified, integrated to users...
>
> LTTNG has been going on for how many years? I havent seen many
> steps towards actually *merging* its functionality - you insist
> on doing your own random thing, which is different in random
> ways. Yes, some of those random ways may in fact be better than
> what we have upstream - would you be interested in filtering
> those out and pushing them upstream? I certainly would like to
> see that happen.
>
> We want to pick the best features, and throw away current
> upstream code in favor of superior out of tree code - this
> concept of letting crap sit alongside each other when people do
> care i cannot agree with.

Mathieu, a good explaination of what lttng has that the in-kernel
tracing and perf doesn't have would be a good place to start.

thanks,

greg k-h


\
 
 \ /
  Last update: 2011-12-06 22:51    [W:1.687 / U:0.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site