Re: [PATCH 09/11] sched: export task_prio to GPL modules

Ingo Molnar
2011-12-08T05:25:43Z

* Greg KH <greg@kroah.com> wrote:

> > 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 :)

The point being, there's legitimate reasons to refuse crap to an
area that *people care about* in a constructive manner.

There's no rejection of LTTNG in the "hey, go away, you are
doing it wrong" fashion - we are not holding a monopoly on how
instrumentation is supposed to be done and we've been wrong
before.

There's a highly constructive, open attitude towards LTTNG and
has been for years:

" Mathieu, please split it up and integrate/unify it with the
existing instrumentation features of Linux - and if it
replaces existing stuff because an LTTNG component is
superior then so be it. "

Let me repeat it: there's no lack of willingness of cooperation
from the kernel instrumentation subsystem side. There's a lack
of movement from Mathieu - *he* is keeping LTTNG fragmented for
barely justifyable technological reasons.

Thus there's absolutely no forward movement from having this in
drivers/staging/ - in fact there's backwards movement: yet
another instrumentation gadget with its own separate ABI and
highly overlapping functionality, plus even less incentive for
it to cooperate...

It is not the typical drivers/staging/ situation where there's
either lack of work on a piece of code or some fundamental
disagreement about the right model. LTTNG has been
*intentionally* kept a separate entity, a separate brand, for
whatever non-technical reasons. How will drivers/staging/ change
that? It won't. It's a bit like VirtualBox really.

In short: this move only *increases* the incentive for LTTNG to
stay fragmented and/or force modularization crap like the highly
unfortunate situation of security modules ...

> > 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.

It wasnt resubmitted for years - see the pattern and see the
problem? :-)

Merging it will cause even *less* cooperation, because of the
reasons above and because LTTNG adds a parallel ABI.

> 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.

LTT(NG) was simply the historically first tracing toolkit that
embedded people got used to and there's still some inertia - and
distros add a lot of crap that people find marginally useful
which perpetuates the fork if there's at least one active
developer behind it. Most of its functionality is available via
existing upstream functionality - and where not we are more than
willing to accomodate patches!

drivers/staging/ is a tool that i support in many (in fact most)
cases - but i don't support it if it does harm.

I'm supposed to say 'no' to extra complexity more often, and
this is definitely one of those cases:

Nacked-by: Ingo Molnar <mingo@elte.hu>

Also obviously NAK to the scheduler symbol export - that alone
should tell you that it's not just a "driver" - it deeply hooks
into the core kernel...

Please respect the NAK.

Thanks,

Ingo