* Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 03/18/2010 12:50 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi@xxxxxxxxxx> wrote:
> >
> >>>The moment any change (be it as trivial as fixing a GUI detail or as
> >>>complex as a new feature) involves two or more packages, development speed
> >>>slows down to a crawl - while the complexity of the change might be very
> >>>low!
> >>Why is that?
> > It's very simple: because the contribution latencies and overhead compound,
> > almost inevitably.
>
> It's not inevitable, if the projects are badly run, you'll have high
> latencies, but projects don't have to be badly run.
So the 64K dollar question is, why does Qemu still suck?
>
> >If you ever tried to implement a combo GCC+glibc+kernel feature you'll know
> >...
> >
> >Even with the best-run projects in existence it takes forever and is very
> >painful - and here i talk about first hand experience over many years.
>
> Try sending a patch to qemu-devel@, you may be pleasantly surprised.
>
>
> >>I the maintainers of all packages are cooperative and responsive, then the
> >>patches will get accepted quickly. If they aren't, development will be
> >>slow. [...]
> >I'm afraid practice is different from the rosy ideal you paint there. Even
> >with assumed 'perfect projects' there's always random differences between
> >projects, causing doubled (tripled) overhead and compounded up overhead:
> >
> > - random differences in release schedules
> >
> > - random differences in contribution guidelines
> >
> > - random differences in coding style
>
> None of these matter for steady contributors.
>
> >>[...] It isn't any different from contributing to two unrelated kernel
> >>subsystems (which are in fact in different repositories until the next merge
> >>window).
> >You mention a perfect example: contributing to multipe kernel subsystems. Even
> >_that_ is very noticeably harder than contributing to a single subsystem - due
> >to the inevitable buerocratic overhead, due to different development trees,
> >due to different merge criteria.
> >
> >So you are underlining my point (perhaps without intending to): treating
> >closely related bits of technology as a single project is much better.
> >
> > Obviously arch/x86/kvm/, virt/ and tools/kvm/ should live in a single
> > development repository (perhaps micro-differentiated by a few topical
> > branches), for exactly those reasons you mention.
>
> How is a patch for the qemu GUI eject button and the kvm shadow mmu related?
> Should a single maintainer deal with both?
We have co-maintainers for perf that have a different focus. It works pretty
well.
Look at git log tools/perf/ and how user-space and kernel-space components
interact in practice. You'll patches that only impact one side, but you'll see
very big overlap both in contributor identity and in patches as well.
Also, let me put similar questions in a bit different way:
- ' how is an in-kernel PIT emulation connected to Qemu's PIT emulation? '
- ' how is the in-kernel dynticks implementation related to Qemu's
implementation of hardware timers? '
- ' how is an in-kernel event for a CD-ROM eject connected to an in-Qemu
eject event? '
- ' how is a new hardware virtualization feature related to being able to
configure and use it via Qemu? '
- ' how is the in-kernel x86 decoder/emulator related to the Qemu x86
emulator? '
- ' how is the performance of the qemu GUI related to the way VGA buffers are
mapped and accelerated by KVM? '
They are obviously deeply related. The quality of a development process is not
defined by the easy cases where no project unification is needed. The quality
of a development process is defined by the _difficult_ cases.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
