Am 30.11.2011 22:03, schrieb Anthony Liguori:
Links represent an ephemeral relationship between devices. They are meant to
replace the qdev concept of busses by allowing more informal relationships
between devices.
Links are fairly limited in their usefulness without implementing QOM-style
On 12/02/2011 06:15 AM, Kevin Wolf wrote:
Am 30.11.2011 22:03, schrieb Anthony Liguori:
Links represent an ephemeral relationship between devices. They are meant to
replace the qdev concept of busses by allowing more informal relationships
between devices.
Links are fairly limited in their
On Wed, Nov 30, 2011 at 03:03:37PM -0600, Anthony Liguori wrote:
+/**
+ * @qdev_property_add_link - Add a link property to a device
+ *
+ * Links establish relationships between devices. Links are unidirection
s/unidirection/unidirectional/
On 11/30/2011 11:03 PM, Anthony Liguori wrote:
Links represent an ephemeral relationship between devices. They are meant to
replace the qdev concept of busses by allowing more informal relationships
between devices.
So, links are equivalent to pointers?
Links are fairly limited in their
On Thu, Dec 1, 2011 at 11:21 AM, Avi Kivity a...@redhat.com wrote:
On 11/30/2011 11:03 PM, Anthony Liguori wrote:
Links represent an ephemeral relationship between devices. They are meant to
replace the qdev concept of busses by allowing more informal relationships
between devices.
So,
On 12/01/2011 01:35 PM, Stefan Hajnoczi wrote:
+static void qdev_get_link_property(DeviceState *dev, Visitor *v, void
*opaque,
+ const char *name, Error **errp)
+{
+DeviceState **child = opaque;
+gchar *path;
+
+if (*child) {
+
On 12/01/2011 04:55 AM, Stefan Hajnoczi wrote:
On Wed, Nov 30, 2011 at 03:03:37PM -0600, Anthony Liguori wrote:
+/**
+ * @qdev_property_add_link - Add a link property to a device
+ *
+ * Links establish relationships between devices. Links are unidirection
s/unidirection/unidirectional/
On 12/01/2011 05:21 AM, Avi Kivity wrote:
On 11/30/2011 11:03 PM, Anthony Liguori wrote:
Links represent an ephemeral relationship between devices. They are meant to
replace the qdev concept of busses by allowing more informal relationships
between devices.
So, links are equivalent to
On 12/01/2011 06:34 AM, Avi Kivity wrote:
On 12/01/2011 01:35 PM, Stefan Hajnoczi wrote:
+static void qdev_get_link_property(DeviceState *dev, Visitor *v, void *opaque,
+ const char *name, Error **errp)
+{
+DeviceState **child = opaque;
+gchar *path;
+
On 12/01/2011 03:47 PM, Anthony Liguori wrote:
On 12/01/2011 06:34 AM, Avi Kivity wrote:
On 12/01/2011 01:35 PM, Stefan Hajnoczi wrote:
+static void qdev_get_link_property(DeviceState *dev, Visitor *v,
void *opaque,
+ const char *name, Error **errp)
+{
+
On 12/01/2011 03:44 PM, Anthony Liguori wrote:
So, links are equivalent to pointers?
Yup. Once we have qom inheritance (next stage), we can have a
linkPCIDevice property and you'll be able to set it to an E1000State
with the appropriate casting and error checking taking place.
I really
On 12/01/2011 08:03 AM, Avi Kivity wrote:
On 12/01/2011 03:44 PM, Anthony Liguori wrote:
So, links are equivalent to pointers?
Yup. Once we have qom inheritance (next stage), we can have a
linkPCIDevice property and you'll be able to set it to an E1000State
with the appropriate casting and
On 12/01/2011 07:50 AM, Avi Kivity wrote:
On 12/01/2011 03:47 PM, Anthony Liguori wrote:
What if it's called with the output visitor? (warning: confusing
convention).
The reason there's a single Visitor type that works for both input and
output visitors is to make it so you can write a single
On 12/01/2011 04:53 PM, Anthony Liguori wrote:
What does the client code looks like for linkPCIDevice?
I'm not sure what you mean by client code,
This:
but consider a device called UsbController that looks like:
struct UsbController
{
DeviceState parent;
UsbDevice *slave; //
Hi,
In terms of QMP client code, you just do:
qom-set /path/to/usb-controller.slave /some/other/device
Lacks notification. usb-controller doesn't notice that you have plugged
in some usb device and thus can't raise an IRQ to notify the guest ...
cheers,
Gerd
On 12/01/2011 09:00 AM, Avi Kivity wrote:
On 12/01/2011 04:53 PM, Anthony Liguori wrote:
What does the client code looks like for linkPCIDevice?
I'm not sure what you mean by client code,
This:
but consider a device called UsbController that looks like:
struct UsbController
{
On 12/01/2011 05:03 PM, Gerd Hoffmann wrote:
Hi,
In terms of QMP client code, you just do:
qom-set /path/to/usb-controller.slave /some/other/device
Lacks notification. usb-controller doesn't notice that you have plugged
in some usb device and thus can't raise an IRQ to notify the
On 12/01/2011 09:03 AM, Gerd Hoffmann wrote:
Hi,
In terms of QMP client code, you just do:
qom-set /path/to/usb-controller.slave /some/other/device
Lacks notification. usb-controller doesn't notice that you have plugged
in some usb device and thus can't raise an IRQ to notify the
Links represent an ephemeral relationship between devices. They are meant to
replace the qdev concept of busses by allowing more informal relationships
between devices.
Links are fairly limited in their usefulness without implementing QOM-style
subclassing and interfaces.
Signed-off-by: Anthony
19 matches
Mail list logo
