Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule

[Avi Kivity]

Anthony Liguori wrote:
> > I don't understand the question.  The relative path is set up once 
> > (in .gitmodules), and that's it.
>
> To clone kvm-kvm.git, you have to do:
>
> [1] git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-kmod.git
> [2] git clone git://git.kernel.org/pub/scm/virt/kvm/kvm.git
> [3] cd kvm-kmod.git
> [4] git submodule update --init
>
> For qemu.git, we'll have to repeat [2] for every ROM we include which 
> will at least be 6 different repositories.  Contrast that to my 
> patchset where there's always 3 steps regardless of how many ROMs we 
> include.

Step 2 is unneeded.  Step 4 takes care of the cloning.  The relative 
path is relative to the repository you cloned kvm-kmod.git _from_.

So, if you cloned git://git.kernel.org/pub/scm/virt/kvm-kmod.git, git 
will clone git://git.kernel.org/pub/scm/virt/kvm.git.  But if you cloned 
http://git.kernel.org/pub/scm/virt/kvm-kmod.git, git will clone kvm.git 
using the http protocol.

Similarly, if you set up a mirror somewhere, as long as kvm-kmod.git and 
kvm.git are under the same directory, cloning kvm-kmod.git will carry 
kvm.git transparently.

> > > We have a lot of ROMs, so this is potentially very undesirable.  
> > > People can always make local changes to the .gitmodules file.
> >
> > Not if they're a mirror.
>
> The normal course of usage will not involve doing a git submodule 
> update in QEMU.  The only folks who really need to do this are 
> maintainers or people doing ROM development/testing.  I don't think 
> I'm that worried about mirrors considering the target audience.
>
> This is different than kvm-kmod whereas all users must do git 
> submodule updates.

That's true.  I still dislike hardcoding a URL into the repository.  It 
means that some branches become unclonable if you move the repository, 
at least not without manual intervention.

> > Let's only include seabios then and reject all patches to the bochs 
> > bios.  If that doesn't motivate people to switch, nothing will.
>
> I don't think it would be wise to switch the default to seabios until 
> after 0.11.  I'm concerned that there hasn't been enough testing on 
> non-mainstream guests.  I'd like a full release cycle worth of testing.

Agreed.

> The gcc 4.1+ requirement is tough too.  One of the values of switching 
> to seabios was moving to a more common toolchain (bcc=>gcc).  Having 
> new tool chain restricts seems a little unfortunate.

Agreed as well.  I think we can work around this requirement, though.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.