Re: kvm repository unification

Gregory Haskins
2007-03-20T12:58:11Z

>>> On Tue, Mar 20, 2007 at 8:37 AM, in message <45FFD598.2050403-atKUWr5tajBWk0Htik3J/w@public.gmane.org>,
Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
> Gregory Haskins wrote:
>> Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org> wrote:
>>
>>> Managing userspace in subversion and the kernel in git is proving to be
>>> quite a pain. Branches have to be maintained in parallel, tagging is
>>> awkward, and bisection is fairly impossible.
>>>
>>> What do people think about putting libkvm and qemu into the usr
>>> directory of the kernel repo? It's slightly wierd but will make life
>>> generally easier.
>>>
>>
>>
>> That does sounds a little weird, though I know what you mean about managing
> the two disparate repos. I think having one repo makes sense, but I dont
> know if putting that in the kernel tree is the right direction. Is there
> another way? For instance, go back to using /kernel, /libkvm, and /qemu from
> SVN and submitting patches/drops to the kernel tree. I am not advocating SVN
> over GIT either...the new unified repo could be whatever. I think the most
> important thing is having it in one place.
>>
>
> With the paravirt stuff we are placing things all over the kernel, and
> tighter integration with the scheduler and mm infrastructure will make
> having a kernel/ directory impossible.
>

Thats a good point. Note that having things sprinkled all over the kernel verses contained in one place (e.g. /drivers/kvm) doesnt preclude this model that I suggested per se. But perhaps that is too messy to deal with. I think getting them in one repo is more important than which repo. So if you can make the integration with the kernel tree work from a political standpoint, I'd say go for it.

-Greg