lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100318111959.GB2174@elte.hu>
Date:	Thu, 18 Mar 2010 12:19:59 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	Anthony Liguori <anthony@...emonkey.ws>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project


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

> On 03/18/2010 11:22 AM, Ingo Molnar wrote:
> >* Avi Kivity<avi@...hat.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.
> 
> You can't be serious.  I find that the difficulty in contributing a patch 
> has mostly to do with writing the patch, and less with figuring out which 
> email address to send it to.

My own experience and everyone i've talked about such topics (developers and 
distro people) about feature contribution tells the exact opposite: it's much 
harder to contribute features to multiple packages than to a single project.

kernel+library+app features take forever to propagate, and there's constant 
fear of version friction, productization deadlines are uncertain and ABI 
messups are frequent as well due to disjoint testing. Also, each component has 
essential veto power: so if the proposed API or approach is opposed or changed 
in a later stage then that affects (sometimes already committed) changes. If 
you've ever done it you'll know how tedious it is.

This very thread and recent threads about KVM usability demonstrate the same 
complications.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ