From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M5j91-0006mm-0e for qemu-devel@nongnu.org; Sun, 17 May 2009 12:23:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M5j8v-0006mX-Fv for qemu-devel@nongnu.org; Sun, 17 May 2009 12:23:21 -0400 Received: from [199.232.76.173] (port=57952 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5j8v-0006mU-B2 for qemu-devel@nongnu.org; Sun, 17 May 2009 12:23:17 -0400 Received: from mx2.redhat.com ([66.187.237.31]:45613) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M5j8u-0007Hd-K1 for qemu-devel@nongnu.org; Sun, 17 May 2009 12:23:16 -0400 Message-ID: <4A1039EB.4070906@redhat.com> Date: Sun, 17 May 2009 19:23:07 +0300 From: Avi Kivity MIME-Version: 1.0 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> In-Reply-To: <4A1031F4.4050401@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 1/4] Add GPL bios as a submodule List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Glauber Costa , Alex Graf , qemu-devel@nongnu.org, Dustin Kirkland 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. Look at kvm-kmod.git for an example. > > 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. > >> Also, s/roms/firmware/ to be modern. > > ROM is a little more specific in my mind. We had a long debate in IRC > as to what was appropriate to include in pc-bios. One key requirement > is that whatever is there has to be a ROM because of the fact that we > install it in a read-only location in the file system. > > On embedded boards, the entire operating system stack constitutes > "firmware". I'm not sure I agree, but we have more pressing subjects to bikeshed. >> 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. -- error compiling committee.c: too many arguments to function