Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/08/2010 09:11 PM, Paul Brook wrote:
>>
>> Because at some point the base tree will have to be written in C.
>>      
> No. You can start with a completely empty machine.
> We don't/shouldn't need any machine specific C code.
>    

I think you're missing the argument.  I should be possible to create a 
machine entirely from a FDT or via -device options.

However, to continue to support the interfaces that we support today, it 
will be necessary to have C code that manipulates a base device tree.

When a user specifies '-M pc -hda foo.img'  verses '-M versatilepb -hda 
foo.img', the equivalent are two very different operations on a device 
tree.  The former adds an ide disk to the default controller and the 
later potentially creates a new scsi bus and then adds a disk to a 
specific bus.

We could force users to these explicit operations instead of the generic 
options we provide today but we would certain end up having our users 
hate us as a result.

> When I submitted the original qdev code I also posted a proof-of-concept patch
> that built the whole machine based on a config file with no hardcoded
> knowledge of the machine structure.
>    

And in your proof-of-concept patches, you couldn't use -hda or any of 
the other command line options that are currently used.  To support 
those things, something would have to understand the device tree well 
enough to know what -hda is supposed to mean.  That's the point of 
MachineCore.

>> Of course you have to decide where to stop allowing customization, but
>> anyway it will be significantly more complex than a QemuOpts config
>> file.  QemuOpts obviously doesn't have the flexibility to create an
>> entire device tree.
>>      
> Why not?
> The current -device option already provides the majority of the functionality
> required.  Most of the missing bits are incomplete qdev conversion.
> I'm not saying that creating a whole machine via -device options is an elegant
> solution (hence the interest in things like FDT) but in I see no reason why it
> shouldn't work.
>
> IMO all uses of the no_user flag are bugs resulting from incomplete/incorrect
> qdev conversions.
>    

I don't disagree.

Regards,

Anthony Liguori