* 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/
