* Greg KH <greg@xxxxxxxxx> 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@xxxxxxx> 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
