From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M5pTw-00005Z-Ed for qemu-devel@nongnu.org; Sun, 17 May 2009 19:09:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M5pTq-0008SG-Bs for qemu-devel@nongnu.org; Sun, 17 May 2009 19:09:22 -0400 Received: from [199.232.76.173] (port=58385 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5pTq-0008S3-5F for qemu-devel@nongnu.org; Sun, 17 May 2009 19:09:18 -0400 Received: from mail-gx0-f176.google.com ([209.85.217.176]:49139) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M5pTp-00089P-AX for qemu-devel@nongnu.org; Sun, 17 May 2009 19:09:17 -0400 Received: by gxk24 with SMTP id 24so8898382gxk.10 for ; Sun, 17 May 2009 16:09:15 -0700 (PDT) Message-ID: <4A109919.2060408@codemonkey.ws> Date: Sun, 17 May 2009 18:09:13 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule References: <1242574141-18488-1-git-send-email-aliguori@us.ibm.com> <1242574141-18488-2-git-send-email-aliguori@us.ibm.com> <4A103084.2000508@redhat.com> <4A1031F4.4050401@us.ibm.com> <4A1039EB.4070906@redhat.com> In-Reply-To: <4A1039EB.4070906@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Glauber Costa , Anthony Liguori , Dustin Kirkland , qemu-devel@nongnu.org, Alex Graf Avi Kivity wrote: > Anthony Liguori wrote: >>> I really prefer a relative path here, so that people can set up >>> mirrors on an internal server. Also, not everyone can access the >>> git port. It can be worked around, but it's much better to have >>> things working out of the proverbial box. >> >> Do you also include a way to automatically setup the relative path? >> Otherwise, it's a multi-step process for someone to fetch all of the >> git trees for building. > > 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. >> >> 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. >>> Having said all that, I'd rather see seabios here. Sure, it will >>> take us time to add missing features, if any, but life will be much >>> more pleasant afterwards. We should reduce our ties to the bochs >>> bios, not tighten them. >> >> Actually, I want to include seabios in here too and install it by >> default. >> >> There's already a -bios option that can be used to change the bios >> file name. After some basic testing, we can decide whether we should >> change the default bios we use. With both installed, it's easier to >> have people check for bugs in one verse the other. > > 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. 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. Regards, Anthony Liguori