On 04/26/2012 01:17 PM, Peter Maydell wrote:
On 26 April 2012 19:10, Anthony Liguori<aligu...@us.ibm.com> wrote:
QOM represents logic objects. It's a data model and when we model hardware,
we can model something concrete (because hardware for the most part has a
physical implementation).
Machines are entirely a QEMU concept.
Not this one again? The real physical beagle board on my desk doesn't
look much like a QEMU concept to me...
So where's your beagle board's "serial_hds[]" array inputs? Where can I put a
DriveInfo into it?
Not everything needs to be modeled as a device. The QEMUMachine for a beagle
board ought to have an init function that looks like:
void machine_init()
{
BeagleBoard *bb = BEAGLE_BOARD(object_new(TYPE_BEAGLE_BOARD));
for (i = 0; serial_hds[i]; i++) {
// add a UART connected to GPIO pins off of the beagle board
}
for (i = 0; net_drives[i]; i++) {
// add a USB-net connected to the USB controller on bb
}
}
But I think modeling a BeagleBoard as a device with an array of CharDriverState
links with logic in realize to do the above is a bit silly. Just because we
could do that doesn't mean we should.
Regards,
Anthony Liguori
There's logic in the machines that
will never be able to be expressed in a config file.
So? There's logic in a UART model that won't be able to be expressed
in a config file, that doesn't constitute an argument for it not
being a QOM object.
-- PMM
