On 02/09/2011 09:15 PM, Blue Swirl wrote:
On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori<anthony@xxxxxxxxxxxxx> wrote:
On 02/09/2011 06:48 PM, Blue Swirl wrote:
ISASerialState dev;
isa_serial_init(&dev, 0, 0x274, 0x07, NULL, NULL);
Do you mean that there should be a generic way of doing that, like
sysbus_create_varargs() for qdev, or just add inline functions which
hide qdev property setup?
I still think that FDT should be used in the future. That would
require that the properties can be set up mechanically, and I don't
see how your proposal would help that.
Yeah, I don't think that is a good idea anymore. I think this is part of
why we're having so many problems with qdev.
While (most?) hardware hierarchies can be represented by device tree syntax,
not all valid device trees correspond to interface and/or useful hardware
hierarchies.
User creates a non-working machine and so gets to fix the problems?
How is that a problem for us?
It's not about creating a non-working machine. It's about what
user-level abstraction we need to provide.
It's a whole lot easier to implement an i440fx device with a fixed set
of parameters than it is to make every possible subdevice have a proper
factory interface along with mechanisms to hook everything together.
Basically, we're making things much harder for ourselves than we should.
We want to have an interface to create large chunks of hardware (like an
i440fx) which then results in a significant portion of a device tree.
But how would this affect interface to devices? I don't see how that
would be any different with current model and the function call model.
If all composition is done through a factory interface, it doesn't. But
my main argument here is that we shouldn't try to make all composition
done through a factory interface--only where it makes sense.
So very concretely, I'm suggesting we do the following to target-i386:
1) make the i440fx device have an embedded ide controller, piix3, and
usb controller that get initialized automatically. The piix3 embeds the
PCI-to-ISA bridge along with all of the default ISA devices (rtc,
serial, etc.).
2) get rid of the entire concept of machines. Creating a i440fx is
essentially equivalent to creating a bare machine.
3) just use the existing -device infrastructure to support all of this.
A very simple device config corresponds to a very complex device tree
but that's the desired effect.
4) model the CPUs as devices that take a pointer to a host controller,
for x86, the normal case would be giving it a pointer to i440fx.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
