On Wed, Jun 9, 2010 at 8:52 PM, Anthony Liguori <anth...@codemonkey.ws> wrote:
> On 06/09/2010 03:47 PM, Blue Swirl wrote:
>>
>> On Wed, Jun 9, 2010 at 2:30 PM, Paul Brook<p...@codesourcery.com> 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.
>>>>
>>>
>>> AFAICS the current commandline options only result in simple addition of
>>> devices. They might add slightly different devices in slightly different
>>> places, but that's easy to accommodate by having the machine define a few
>>> standard device/bus IDs.
>>>
>>> IMO it's even more lame if -hda shops working when you supply a device
>>> tree.
>>>
>>
>> The tree supplied by the user should label a bus node with a property
>> 'QEMU,hda'. The C version (called by the board) would be something
>> like setprop("/i440fx/pci.0/ide.0", "QEMU,hda"). QEMU should search
>> the device tree for such labels at startup.
>>
>
> That works for the very simple case of -hda, but what do you do for:
>
> -drive file=foo.img,bus=0,index=2
This is a host device, so the device tree does not address that. But
previously I proposed that also the host devices (drives, chardev,
netdev etc.) could be considered to be qdev like devices and qemu_irqs
could be used to communicate between the host devices and
machine/board. Maybe that should be reconsidered.
> I think it's possible to come up with some form of solution once you start
> adding synthetic properties or dummy devices but ultimately I think it
> pollutes the device tree. I think the easiest way to support the interfaces
> we provide now is to just code the device tree manipulation in C.
I don't think pollution is a problem with careful prefixing, also
Linux adds some properties to its device tree. We could also prune our
properties from the tree before passing it around if necessary.
