On 07/28/2011 07:59 PM, Anthony Liguori wrote:
Just define an interface that returns a struct then. It's no more
complicated than that.
Ok, so we're debating whether to: 1) add an interface returning a
pointer to an internal struct; 2) include in the internal struct a
pointer-to-function
On 07/27/2011 10:01 PM, Anthony Liguori wrote:
That's milkymist, not GoldFish.
Oh, Goldfish is fake. It's not real hardware.
The enumerator device is not a real device. It's weird because it's
imaginary and was designed specifically within QEMU.
It's not a good example for discussing
On 07/28/2011 02:36 AM, Paolo Bonzini wrote:
On 07/27/2011 10:01 PM, Anthony Liguori wrote:
That's milkymist, not GoldFish.
Oh, Goldfish is fake. It's not real hardware.
The enumerator device is not a real device. It's weird because it's
imaginary and was designed specifically within
On 07/28/2011 02:46 PM, Anthony Liguori wrote:
There are plenty of PV interfaces implemented by QEMU. Would you say the
same of virtio?
Virtio was designed to look like real hardware.
I would say that trying to fit XenStore into QOM would not be a good
exercise.
No doubt about that. :)
On 07/28/2011 08:50 AM, Paolo Bonzini wrote:
On 07/28/2011 02:46 PM, Anthony Liguori wrote:
There are plenty of PV interfaces implemented by QEMU. Would you say the
same of virtio?
Virtio was designed to look like real hardware.
I would say that trying to fit XenStore into QOM would not be
On 07/28/2011 04:03 PM, Anthony Liguori wrote:
No doubt about that. :) I'd put a lot more hope into Goldfish though.
What's unclear to me about the Goldfish enumerator is whether it should
be filled out through interaction with hardware devices or via some
other mechanism.
In many ways, it's
On 07/28/2011 09:41 AM, Paolo Bonzini wrote:
On 07/28/2011 04:03 PM, Anthony Liguori wrote:
No doubt about that. :) I'd put a lot more hope into Goldfish though.
What's unclear to me about the Goldfish enumerator is whether it should
be filled out through interaction with hardware devices or
On 07/28/2011 05:04 PM, Anthony Liguori wrote:
The only way I can see is to teach each device about this interface and
then have a common bus. That implies that you have:
class GoldfishEnumerator : public Device {
GoldfishDevice *slots[N];
FWIW, there's no hardcoded limit in the
On 07/28/2011 10:47 AM, Paolo Bonzini wrote:
On 07/28/2011 05:04 PM, Anthony Liguori wrote:
The only way I can see is to teach each device about this interface and
then have a common bus. That implies that you have:
class GoldfishEnumerator : public Device {
GoldfishDevice *slots[N];
FWIW,
On 07/26/2011 09:23 PM, Anthony Liguori wrote:
On 07/26/2011 01:26 PM, Paolo Bonzini wrote:
On 07/26/2011 05:34 PM, Anthony Liguori wrote:
You could just as well say that real life works like this:
class PciSocket {
PciBus *pci_bus;
uint8_t *config;
uint8_t *cmask;
uint8_t *wmask;
uint8_t
On 07/27/2011 03:55 AM, Paolo Bonzini wrote:
Yes, this looks nice (modulo s/Rtl8139/Rtl8139 */). But it is not that
much more flexible than qdev 1.0.
You're right that for the case of two parents above we were looking at a
contrived example. The Goldfish platform provides a more interesting
On 07/27/2011 02:48 PM, Anthony Liguori wrote:
So the idea here is that the PIC will multiplex a bunch of interrupts
into a single line?
Yes, but the device needs to know the interrupt number so it can expose
it through the enumerator interface. So the configuration cannot be simply
On 07/27/2011 10:33 AM, Paolo Bonzini wrote:
On 07/27/2011 02:48 PM, Anthony Liguori wrote:
So the idea here is that the PIC will multiplex a bunch of interrupts
into a single line?
Yes, but the device needs to know the interrupt number so it can expose
it through the enumerator interface.
On 07/27/2011 10:33 AM, Paolo Bonzini wrote:
On 07/27/2011 02:48 PM, Anthony Liguori wrote:
So the idea here is that the PIC will multiplex a bunch of interrupts
into a single line?
Yes, but the device needs to know the interrupt number so it can expose
it through the enumerator interface.
On 07/27/2011 06:28 PM, Anthony Liguori wrote:
On 07/27/2011 10:33 AM, Paolo Bonzini wrote:
On 07/27/2011 02:48 PM, Anthony Liguori wrote:
So the idea here is that the PIC will multiplex a bunch of interrupts
into a single line?
Yes, but the device needs to know the interrupt number so it
On 07/27/2011 01:51 PM, Paolo Bonzini wrote:
On 07/27/2011 06:28 PM, Anthony Liguori wrote:
On 07/27/2011 10:33 AM, Paolo Bonzini wrote:
On 07/27/2011 02:48 PM, Anthony Liguori wrote:
So the idea here is that the PIC will multiplex a bunch of interrupts
into a single line?
Yes, but the
On 26 July 2011 15:02, Anthony Liguori anth...@codemonkey.ws wrote:
In my attempt at PCI modelling, I had something like:
struct I440FX
{
Device parent;
PciDevice slots[32];
};
Which means that to attach to bus 0, slot 3, fn 0, you do:
i440fx-slots[3] = mydevice
So what I don't
On 07/27/2011 04:33 PM, Peter Maydell wrote:
On 26 July 2011 15:02, Anthony Liguorianth...@codemonkey.ws wrote:
In my attempt at PCI modelling, I had something like:
struct I440FX
{
Device parent;
PciDevice slots[32];
};
Which means that to attach to bus 0, slot 3, fn 0, you do:
On 07/25/2011 03:44 AM, Anthony Liguori wrote:
Hi,
This series is the rough beginnings of the QEMU Object Model. This is basically
qdev generalized on steroids.
This series includes the core infrastructure, a strawman Device type, and
the beginnings of the conversion of CharDriverState. This
On 07/26/2011 07:59 AM, Paolo Bonzini wrote:
For host devices (Char/Block/Network) we have a relatively simple
interface but we need a richer way to create and destroy the objects at
runtime. We have it already for block and network, we don't for char,
but it is done ad hoc for each hierarchy.
On 07/26/2011 04:02 PM, Anthony Liguori wrote:
Also because there is no hierarchy, composition in host devices can be
done very easily. A decorator for char/block devices, such as a tee
device, can treat the wrapped object(s) the same independent of the
actual class. A simple vtable works very
On 07/26/2011 09:35 AM, Paolo Bonzini wrote:
On 07/26/2011 04:02 PM, Anthony Liguori wrote:
Also because there is no hierarchy, composition in host devices can be
done very easily. A decorator for char/block devices, such as a tee
device, can treat the wrapped object(s) the same independent of
On 07/26/2011 05:34 PM, Anthony Liguori wrote:
And as such it can add data members. But when a device is on two buses,
you cannot have both of them adding data members. I know MI is hard to
get right, and in fact I'm not proposing to do MI---not even interface
inheritance. I don't want to have
On 07/26/2011 01:26 PM, Paolo Bonzini wrote:
On 07/26/2011 05:34 PM, Anthony Liguori wrote:
And as such it can add data members. But when a device is on two buses,
you cannot have both of them adding data members. I know MI is hard to
get right, and in fact I'm not proposing to do MI---not even
Am 25.07.2011 03:44, schrieb Anthony Liguori:
Hi,
This series is the rough beginnings of the QEMU Object Model. This is
basically
qdev generalized on steroids.
This series includes the core infrastructure, a strawman Device type, and
the beginnings of the conversion of CharDriverState.
On 07/25/2011 06:21 AM, Kevin Wolf wrote:
Am 25.07.2011 03:44, schrieb Anthony Liguori:
Hi,
This series is the rough beginnings of the QEMU Object Model. This is basically
qdev generalized on steroids.
This series includes the core infrastructure, a strawman Device type, and
the beginnings
Am 25.07.2011 14:45, schrieb Anthony Liguori:
On 07/25/2011 06:21 AM, Kevin Wolf wrote:
Am 25.07.2011 03:44, schrieb Anthony Liguori:
Hi,
This series is the rough beginnings of the QEMU Object Model. This is
basically
qdev generalized on steroids.
This series includes the core
On 07/25/2011 08:08 AM, Kevin Wolf wrote:
Am 25.07.2011 14:45, schrieb Anthony Liguori:
Okay, if it isn't possible with reasonable effort, I guess we'll have to
bite the bullet and give it a very careful manual review immediately
before the merge.
By the way, I see that you create new
28 matches
Mail list logo
