lkml.org 
[lkml]   [2010]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Unify KVM kernel-space and user-space code into a single project

    * Avi Kivity <avi@redhat.com> wrote:

    > > - move a clean (and minimal) version of the Qemu code base to tools/kvm/,
    > > in the upstream kernel repo, and work on that from that point on.
    >
    > I'll ignore the repository location which should be immaterial to a serious
    > developer and concentrate on the 'clean and minimal' aspect, since it has
    > some merit. [...]

    To the contrary, experience shows that repository location, and in particular
    a shared repository for closely related bits is very much material!

    It matters because when there are two separate projects, even a "serious
    developer" is finding it double and triple difficult to contribute even
    trivial changes.

    It becomes literally a nightmare if you have to touch 3 packages: kernel, a
    library and an app codebase. It takes _forever_ to get anything useful done.

    Also, 'focus on a single thing' is a very basic aspect of humans, especially
    those who do computer programming. Working on two code bases in two
    repositories at once can be very challenging physically and psychically.

    So what i've seen is that OSS programmers tend to pick a side, pretty much
    randomly, and then rationalize it in hindsight why they prefer that side ;-)

    Most of them become either a kernel developer or a user-space package
    developer - and then they specialize on that field and shy away from changes
    that involve both. It's a basic human thing to avoid the hassle that comes
    with multi-package changes. (One really has to be outright stupid, fanatic or
    desperate to even attempt such changes these days - such are the difficulties
    for a comparatively low return.)

    The solution is to tear down such artificial walls of contribution where
    possible. And tearing down the wall between KVM and qemu-kvm seems very much
    possible and the advantages would be numerous.

    Unless by "serious developer" you meant: "developer willing to [or forced to]
    waste time and effort on illogically structured technology".

    > [...]
    >
    > Do you really think the echo'n'cat school of usability wants to write a GUI?
    > In linux-2.6.git?

    Then you'll be surprised to hear that it's happening as we speak and the
    commits are there in linux-2.6.git. Both a TUI and GUI is in the works.

    Furthermore, the numbers show that half of the usability fixes to tools/perf/
    came not from regular perf contributors but from random kernel developers and
    testers who when they build the latest kernel and try out perf at the same
    time (it's very easy because you already have it in the kernel repository - no
    separate download, no installation, etc. necessary).

    I had literally zero such contributions when (the precursor to) 'perf' was
    still a separate user-space project.

    You could have the same effect for Qemu: the latest bits in tools/kvm/ would
    be built by regular kernel testers and developers. The integration benefits
    dont just extend to developers, a unified project is vastly easier to test as
    well.

    Thanks,

    Ingo


    \
     
     \ /
      Last update: 2010-03-18 10:25    [W:4.233 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site