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
