* David Woodhouse <dw...@infradead.org> wrote: > On Mon, 2013-02-11 at 13:56 +0100, Ingo Molnar wrote: > > To use another, perhaps more applicable analogy: > > > > If one has the choice to start a new business in the U.S., it > > would be reasonable to do that. There's a lot of supporting > > infrastructure, trust, distribution, standards, enforcement > > agencies and available workers. > > > > Could the same business succeed in Somalia as well? Possibly - > > if it's a bakery or something similarly fundamental. More > > complex businesses would likely not thrive very well there. > > > > *That* is how I think the current Linux kernel tooling landscape > > looks like currently in a fair number of places: in many aspects > > it's similar to Somalia - disjunct entities with not much > > commonality or shared infrastructure. > > That's complete nonsense. If you want to use pieces of the > kernel infrastructure, then just *take* them. [...]
So I can take the mailing lists and the whole contribution culture? Hardly... I was not talking about code alone, I was also talking about a social environment - which is not a one sided relationship at all, it improves the kernel code, like it already did for over two dozen tools/kvm originated patches: To quote from my mail to Linus: " - Pekka listed new virtio drivers that were done via tools/kvm. - Pekka listed ARM KVM support which was written/prototyped using tools/kvm. - There's over a dozen bugfixes in your kernel which were found via syscall fuzzing built into tools/kvm. (I can dig them all out if you want.) - There are several fixes in the kernel side KVM subsystem itself that were unearthed via tools/kvm. - I showed how it helped the kernel by creating user-space lockdep: code used in more situations means more exposure, more bugfixes and more contributors. (It also allowed immediate lockdep coverage for all the user-space mutexes that tools/perf/ itself uses.) Those were all real benefits to the kernel which are upstream or almost upstream today. This tool alone generated a *more* versatile number of improvements to the kernel than the majority of filesystems and the majority of drivers in the Linux kernel tree today has ever achieved. " > [...] There are loads of projects which use the kernel config > tools, for example. There's no need to be *in* the kernel > repo. > > And for code-reuse it's even easy enough to automatically > extract parts of kernel code into a separate repository. [...] ... which solution would: - lose all history - lose contributor awareness of each other - lose easy cross-contribution pathways That's a severe net minus in my opinion. I think you should try to answer the very fundamental observation I made and the question I asked in my mail to Tytso: " We have first hand experience there: tools/perf/. None of the predicted extreme badness happened. Yes, sometimes we broke compatibility as ABI changes/enhancements do - but treated them as regressions and fixed them. I also think that considering the rate of changes our breakage ratio is very good. So no badness happened, and in fact a lot of goodness happened: which goodness never happened while Linux profiling was a separate project isolated as a user-space utility! Anyone opposing integration I think *HAS* to explain the mechanics behind this very example in plain sight. Why the heck has pretty much every other out of tree profiling project died, while the in-tree one is thriving? Yes, the key is that Arnaldo is good, and so are the other perf contributors - and they are good because they feel at home and they are productive. Being in the kernel repo is actually 90% responsible for that environment! " And yes, based on the evidence I think much of perf's current vitality would be killed off or would be severely reduced if it was forced into a separate, out of tree project. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/