From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJXGR-0004Yu-Re for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:32:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJXGM-0004YT-Uy for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:32:07 -0400 Received: from [199.232.76.173] (port=52045 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJXGM-0004YQ-Ov for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:32:02 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:48561) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJXGM-00007e-3w for qemu-devel@nongnu.org; Wed, 24 Jun 2009 14:32:02 -0400 Received: by ewy7 with SMTP id 7so1366633ewy.34 for ; Wed, 24 Jun 2009 11:32:01 -0700 (PDT) Message-ID: <4A42711C.2030802@codemonkey.ws> Date: Wed, 24 Jun 2009 13:31:56 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4A41285F.40705@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [RFC PATCH 00/15] Be able to compile out not needed options List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: qemu-devel@nongnu.org Juan Quintela wrote: > Anthony Liguori wrote: > >> quintela@redhat.com wrote: >> >>> From: Juan Quintela >>> >>> Hi >>> >>> this series of patches: >>> a- move object files only used by one target to that target Makefile.target >>> b- add flags to disable parts: --disable-{bluez,usb,vwmare,virtio,scsi} >>> defaults is leave it enabled. You need to add the --disable-* flag to get any change >>> c- disable the use of --smb >>> >>> What is the intent: we want to be able to not compile-in things that we are not >>> interested in (they are experimental/not needed for our target/...). >>> >>> Is this the right approach? Should I do something different? >>> >>> For the next series, I am also interested on enable/disabling bits of a subsysem: >>> being able to support usb-hid but not usb-{host,net,msnd}. I already have patches >>> to disable that, just waiting to hear what is the preffered way to get >>> that functionality. >>> >>> Known problems: >>> - qemu-*.hx files don't run over cpp and then we are not able to remove from >>> the help page the options that we don't support. >>> - drive_hot_add without scsi support do nothing. >>> >>> Any comments? >>> >>> >> To me, there are a few fundamental requirements for this: >> >> 1) This be configurable via a .config file instead of via ./configure >> options. >> > > We have config-hosts.mak. > config-host.mak is generated. We need something that isn't generated. > If we don't want to do it with ./configure, with what/how do you want it > to happen. > > Do we agree in having: > > qemu/.config > qemu/.config.mak > target-*/.config > target-*/.config.mak > I don't think we need all of these. I don't think we need separate .mak and .h files. The later can be generated from the former. > The problem that I saw otherwise with current approach is that it > is difficult to have a module linked for one target and not for another. > (No adding yet more ifdefs tricks is not a solution IMHO). > I suspect we will need to restructure Makefile.target to get this working. I'd suggest focusing on host configuration to start with to avoid this problem. >> 2) This involve no additional #ifdefs in the code >> > > That is doable, if we agree that putting stub declarations in .h files > is ok. I was following the "current style". > You usually shouldn't need stubs either. Take for instance, the changes you make for --disable-bluez. First, you'll want to move all the stuff in vl.c that's bluez specific to a separate file. For usb_device_add, you would need to add a registration API that allows registering an emulated usb device. In your new file, in a module load function, you would register bt and the bt: protocol as emulated usb devices. Getting the actual bt options is a bit trickier. I think we have to deal with #ifdefs on that one. We can at least make the bt_parse() calls part of an option parsing callback or something. >> The block/ drivers are the model here. If you drop individual files >> from the build, it Just Works. >> > > But block/ drivers are _easy_ in this regard, you only have to register > a struct, and they become available. USB/SCSI/... touch code in the > middle of pc.c and the other platforms "machine" files. > Yes, that's precisely what we want to fix :-) block is easy because a lot of work was put into making it well isolated from everything else. It's the new model for how the rest of QEMU should look :-) > On the other hand, block implementation is not flexible enough for us > yet (TM). We would like to be able to complie all block drivers for > qemu-img and only some of them for qemu :) > That's an interesting idea. > Will redo the patches with this (and the other people suggestions). > > Thank for the input, Juan. > Thanks for taking up this effort! Regards, Anthony Liguori