[Qemu-devel] Re: [RFC PATCH 00/15] Be able to compile out not needed options

[Anthony Liguori <anthony@codemonkey.ws>]

Juan Quintela wrote:
> Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>> quintela@redhat.com wrote:
>>     
>>> From: Juan Quintela <quintela@redhat.com>
>>>
>>> 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 <dir>
>>>
>>> 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