> I also don't want the user to have to always make the decision about how to
> hook up IRQs for every single device because in a lot of circumstances,
> there's no point.
How else are we going to figure out how the IRQ lines are wired up?
> A basic premise for me is that simple things should be
On 12/15/2011 03:28 PM, Paul Brook wrote:
There is a second class of "user" that is doing very sophisticated things
and cares about this information. But this sophisticated user (i.e.
libvirt) wants to be able to probe QEMU to understand what features
are probably available because it very likel
> But there are two distinct classes of user. One class of user really is
> thinking:
>
> "I want a KVM virtual machine, with 3 disks and 2 network cards"
>
> They could give a flying hoot whether the i440fx inherits from pcidevice or
> implements pcibus.
>
> We need to provide an obviously dis
On 12/15/2011 12:59 PM, Paul Brook wrote:
Do we have a user interface issue here?
I want to separate backwards compatibility from ABI compatibility. We
should provide nice high level interfaces that are forever backwards
compatible. But when it comes to hooking up IRQs between devices, that
i
> > Do we have a user interface issue here?
>
> I want to separate backwards compatibility from ABI compatibility. We
> should provide nice high level interfaces that are forever backwards
> compatible. But when it comes to hooking up IRQs between devices, that
> interface should just be ABI com
On 12/14/2011 04:46 PM, Anthony Liguori wrote:
>> Well, that's exactly what I had in mind (except that you'd bounce the
>> I/O to an AddressSpace, which takes care of preparing the dispatch
>> tables etc. instead of searching dynamically through the hierarchy).
>
>
> But the I/O table for the Addre
On 12/14/2011 08:35 AM, Avi Kivity wrote:
On 12/14/2011 04:11 PM, Anthony Liguori wrote:
We discussed it before and I believe he was planning on adding
itl_shift as a MemoryRegion mutator.
I don't think it makes sense as a mutator, can it_shift change
dynamically? But as part of setup, ye
On 12/14/2011 04:11 PM, Anthony Liguori wrote:
>> In fact I want the ability to create new address spaces. For example
>> index/data style interfaces, as found in RTC, IOAPIC, and PCI 0xcf8
>> style config space, can be hooked to drive an RTC MemoryRegion, an
>> IOAPIC MemoryRegion, and the PCI co
On 12/14/2011 08:01 AM, Avi Kivity wrote:
On 12/14/2011 03:53 PM, Anthony Liguori wrote:
The fact that serial.c (which really should be called 16550.c)
contains ISA
specific IO callback routines feels like ISASerial isn't doing its job
proberly to start with :-)
It's not really ISA specific c
On 12/14/2011 03:53 PM, Anthony Liguori wrote:
>> The fact that serial.c (which really should be called 16550.c)
>> contains ISA
>> specific IO callback routines feels like ISASerial isn't doing its job
>> proberly to start with :-)
>
>
> It's not really ISA specific callbacks but I need to think t
On 12/13/2011 06:39 PM, Paul Brook wrote:
Composition == "etching to the same piece of silicon". Nothing more,
nothing less.
That's a really crappy definition. Most ARM systems are comprised of
approximately one piece of silicon. There may be dozens of variants of a
particular chip, with the
Am 13.12.2011 22:53, schrieb Anthony Liguori:
> ISADevice could very easily become an Interface as it has no
> state today.
Not in upstream, but Hervé and me had been working on that for PReP, as
you may recall.
There seemed to be consensus that some ISA devices can choose which I/O
ports and IRQ
> >> Composition == "etching to the same piece of silicon". Nothing more,
> >> nothing less.
> >
> > That's a really crappy definition. Most ARM systems are comprised of
> > approximately one piece of silicon. There may be dozens of variants of a
> > particular chip, with the same device models
On 12/13/2011 02:36 PM, Paul Brook wrote:
Composition == "etching to the same piece of silicon". Nothing more,
nothing less.
That's a really crappy definition. Most ARM systems are comprised of
approximately one piece of silicon. There may be dozens of variants of a
particular chip, with the
> > That still leaves both PCIDevice and SysBusDevice state. The i440fx
> > is a fairly simple device, but more complex bridges have additional state
> > that needs to be accessible from both the PCI and SysBus interfaces.
>
> SysBus is so badly abused today I think we would have to reevaluate wh
On 12/13/2011 11:40 AM, Paul Brook wrote:
It's multiple inheritance but interfaces (implements) cannot carry state
which avoids an inheritance diamond problem.
It sounds like some
form of multiple inheritance, but it's unclear to me which should be the
primary type. For PCI host bridges like
> It's multiple inheritance but interfaces (implements) cannot carry state
> which avoids an inheritance diamond problem.
> > It sounds like some
> > form of multiple inheritance, but it's unclear to me which should be the
> > primary type. For PCI host bridges like the i440fx we currently have t
On 12/12/2011 10:47 PM, Paul Brook wrote:
The full set of devices names and properties used in this example are
below:
Type: I440FX
Is-a: Device
Implements: PciBus
Name: i440fx
Properties:
piix3: Composition
slot[1.0]: Backlink
Type: PIIX3
Isa-a: PciDevice
Implem
> The full set of devices names and properties used in this example are
> below:
>
> Type: I440FX
> Is-a: Device
> Implements: PciBus
> Name: i440fx
> Properties:
>piix3: Composition
>slot[1.0]: Backlink
>
> Type: PIIX3
> Isa-a: PciDevice
> Implements: IsaBus
> Name: i44
On 09/18/2011 10:56 AM, Avi Kivity wrote:
On 09/15/2011 11:52 PM, Anthony Liguori wrote:
Also, NE2000 methods have to call ISA_NE2000 and PCI_NE2000 methods,
yes?
I don't think so. The NE2k would export an IRQ and the ISA_NE2K and
PCI_NE2k would have to route that IRQ. But I think that's t
On 09/15/2011 11:52 PM, Anthony Liguori wrote:
Also, NE2000 methods have to call ISA_NE2000 and PCI_NE2000 methods,
yes?
I don't think so. The NE2k would export an IRQ and the ISA_NE2K and
PCI_NE2k would have to route that IRQ. But I think that's the extent
of the communication in that dir
On Fri, Sep 16, 2011 at 09:17:54PM -0500, Anthony Liguori wrote:
> On 09/16/2011 07:48 PM, Edgar E. Iglesias wrote:
> >On Fri, Sep 16, 2011 at 07:47:57PM +0300, Gleb Natapov wrote:
> >>On Thu, Sep 15, 2011 at 03:50:28PM -0500, Anthony Liguori wrote:
> >>>On 09/15/2011 03:29 PM, Gleb Natapov wrote:
On Fri, Sep 16, 2011 at 09:12:19PM -0500, Anthony Liguori wrote:
> On 09/16/2011 08:11 PM, Edgar E. Iglesias wrote:
> >On Fri, Sep 16, 2011 at 11:10:19AM -0500, Anthony Liguori wrote:
> >>On 09/16/2011 09:46 AM, John Williams wrote:
> >>>On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori
> >>>wro
On 09/16/2011 09:17 PM, Anthony Liguori wrote:
On 09/16/2011 07:48 PM, Edgar E. Iglesias wrote:
QEMU should allow us to model devices in a a bus agnostic way.
And this is the problem to fix in qdev. We need to kill buses in qdev. The
approach really boils down to:
1) Add unique names to devic
On 09/16/2011 07:48 PM, Edgar E. Iglesias wrote:
On Fri, Sep 16, 2011 at 07:47:57PM +0300, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 03:50:28PM -0500, Anthony Liguori wrote:
On 09/15/2011 03:29 PM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 12:51:23PM -0500, Anthony Liguori wrote:
On 09/15
On 09/16/2011 08:11 PM, Edgar E. Iglesias wrote:
On Fri, Sep 16, 2011 at 11:10:19AM -0500, Anthony Liguori wrote:
On 09/16/2011 09:46 AM, John Williams wrote:
On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori
wrote:
On 09/15/2011 01:31 AM, Gleb Natapov wrote:
On Wed, Sep 14, 2011 at 01:04
On Fri, Sep 16, 2011 at 11:10:19AM -0500, Anthony Liguori wrote:
> On 09/16/2011 09:46 AM, John Williams wrote:
> >On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori
> >wrote:
> >>On 09/15/2011 01:31 AM, Gleb Natapov wrote:
> >>>
> >>>On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote
On Fri, Sep 16, 2011 at 07:47:57PM +0300, Gleb Natapov wrote:
> On Thu, Sep 15, 2011 at 03:50:28PM -0500, Anthony Liguori wrote:
> > On 09/15/2011 03:29 PM, Gleb Natapov wrote:
> > >On Thu, Sep 15, 2011 at 12:51:23PM -0500, Anthony Liguori wrote:
> > >>On 09/15/2011 11:59 AM, Gleb Natapov wrote:
>
On Fri, Sep 16, 2011 at 01:42:02PM -0500, Anthony Liguori wrote:
> On 09/16/2011 01:22 PM, Gleb Natapov wrote:
> >Then we are arguing about minor detail. But according to you this minor
> >detail will prevent us from walking device tree up to the root, so it is
> >not so minor for me.
>
> There is
On 09/16/2011 03:48 PM, Gleb Natapov wrote:
On Fri, Sep 16, 2011 at 02:29:51PM -0500, Anthony Liguori wrote:
On 09/16/2011 02:13 PM, Gleb Natapov wrote:
On Fri, Sep 16, 2011 at 01:42:02PM -0500, Anthony Liguori wrote:
On 09/16/2011 01:22 PM, Gleb Natapov wrote:
Then we are arguing about minor
On Fri, Sep 16, 2011 at 02:29:51PM -0500, Anthony Liguori wrote:
> On 09/16/2011 02:13 PM, Gleb Natapov wrote:
> >On Fri, Sep 16, 2011 at 01:42:02PM -0500, Anthony Liguori wrote:
> >>On 09/16/2011 01:22 PM, Gleb Natapov wrote:
> >>>Then we are arguing about minor detail. But according to you this m
On 09/16/2011 02:13 PM, Gleb Natapov wrote:
On Fri, Sep 16, 2011 at 01:42:02PM -0500, Anthony Liguori wrote:
On 09/16/2011 01:22 PM, Gleb Natapov wrote:
Then we are arguing about minor detail. But according to you this minor
detail will prevent us from walking device tree up to the root, so it
On Fri, Sep 16, 2011 at 01:42:02PM -0500, Anthony Liguori wrote:
> On 09/16/2011 01:22 PM, Gleb Natapov wrote:
> >Then we are arguing about minor detail. But according to you this minor
> >detail will prevent us from walking device tree up to the root, so it is
> >not so minor for me.
>
> There is
On 09/16/2011 01:22 PM, Gleb Natapov wrote:
Then we are arguing about minor detail. But according to you this minor
detail will prevent us from walking device tree up to the root, so it is
not so minor for me.
There is no root. It's not a tree. The composition tree (which we've been
talking
On Fri, Sep 16, 2011 at 01:08:27PM -0500, Anthony Liguori wrote:
> On 09/16/2011 12:47 PM, Peter Maydell wrote:
> >On 16 September 2011 17:33, Gleb Natapov wrote:
> >>On Thu, Sep 15, 2011 at 09:45:33PM +0100, Peter Maydell wrote:
> >>>On 15 September 2011 21:29, Gleb Natapov wrote:
> 16650A i
On Fri, Sep 16, 2011 at 06:47:56PM +0100, Peter Maydell wrote:
> On 16 September 2011 17:33, Gleb Natapov wrote:
> > On Thu, Sep 15, 2011 at 09:45:33PM +0100, Peter Maydell wrote:
> >> On 15 September 2011 21:29, Gleb Natapov wrote:
> >> > 16650A is not a device. ISA card it resides on is a devic
On 09/16/2011 12:47 PM, Peter Maydell wrote:
On 16 September 2011 17:33, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 09:45:33PM +0100, Peter Maydell wrote:
On 15 September 2011 21:29, Gleb Natapov wrote:
16650A is not a device. ISA card it resides on is a device.
The 16550A is an encapsula
On 16 September 2011 17:33, Gleb Natapov wrote:
> On Thu, Sep 15, 2011 at 09:45:33PM +0100, Peter Maydell wrote:
>> On 15 September 2011 21:29, Gleb Natapov wrote:
>> > 16650A is not a device. ISA card it resides on is a device.
>>
>> The 16550A is an encapsulated set of functionality with some
>
On Thu, Sep 15, 2011 at 03:50:28PM -0500, Anthony Liguori wrote:
> On 09/15/2011 03:29 PM, Gleb Natapov wrote:
> >On Thu, Sep 15, 2011 at 12:51:23PM -0500, Anthony Liguori wrote:
> >>On 09/15/2011 11:59 AM, Gleb Natapov wrote:
> >>>On Thu, Sep 15, 2011 at 11:33:00AM -0500, Anthony Liguori wrote:
>
On Thu, Sep 15, 2011 at 09:45:33PM +0100, Peter Maydell wrote:
> On 15 September 2011 21:29, Gleb Natapov wrote:
> > 16650A is not a device. ISA card it resides on is a device.
>
> The 16550A is an encapsulated set of functionality with some
> well defined interfaces ("I provide a set of memory m
On 09/16/2011 09:46 AM, John Williams wrote:
On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori wrote:
On 09/15/2011 01:31 AM, Gleb Natapov wrote:
On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
All device relationships are identified as named properties. A QOM
path name
co
On Thu, Sep 15, 2011 at 11:17 PM, Anthony Liguori wrote:
> On 09/15/2011 01:31 AM, Gleb Natapov wrote:
>>
>> On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
>>>
>>> All device relationships are identified as named properties. A QOM
>>> path name
>>> consists of a named device, fo
On 09/16/2011 05:12 AM, Kevin Wolf wrote:
Am 15.09.2011 16:11, schrieb Anthony Liguori:
An example is a NIC with nvram that stores a mac address. In QOM, the guest
could change the mac address, then a user could hot unplug the device, and then
hot plug the device into a different PCI slot. The
Am 15.09.2011 16:11, schrieb Anthony Liguori:
> On 09/15/2011 08:43 AM, Jan Kiszka wrote:
>> On 2011-09-15 00:11, Anthony Liguori wrote:
>>> On 09/14/2011 04:15 PM, Jan Kiszka wrote:
On 2011-09-14 21:42, Anthony Liguori wrote:
>> Such names can get fairly long I'm afraid...
>
> A u
Hi,
Also, NE2000 methods have to call ISA_NE2000 and PCI_NE2000 methods,
yes? That's going to be more difficult. Not impossible, just hard. It's
probably going to involve device specific code that models what type of
glue was used for that particular device/bus combo.
I'd expect our new, shi
On 09/15/2011 03:45 PM, Peter Maydell wrote:
On 15 September 2011 21:29, Gleb Natapov wrote:
16650A is not a device. ISA card it resides on is a device.
The 16550A is an encapsulated set of functionality with some
well defined interfaces ("I provide a set of memory mapped
registers", "I have
On 09/15/2011 03:23 PM, Avi Kivity wrote:
On 09/15/2011 04:26 PM, Anthony Liguori wrote:
I think this model is the closest to what we have today and is the most
obvious. For something like ne2k, I would expect:
class NE2000 : public Device
{
// ne2k public functions
};
class PCI_NE2000 : publ
On 09/15/2011 03:29 PM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 12:51:23PM -0500, Anthony Liguori wrote:
On 09/15/2011 11:59 AM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 11:33:00AM -0500, Anthony Liguori wrote:
On 09/15/2011 10:38 AM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 10:28:5
On 15 September 2011 21:29, Gleb Natapov wrote:
> 16650A is not a device. ISA card it resides on is a device.
The 16550A is an encapsulated set of functionality with some
well defined interfaces ("I provide a set of memory mapped
registers", "I have an output gpio line (irq)"), which we
need to b
On Thu, Sep 15, 2011 at 12:51:23PM -0500, Anthony Liguori wrote:
> On 09/15/2011 11:59 AM, Gleb Natapov wrote:
> >On Thu, Sep 15, 2011 at 11:33:00AM -0500, Anthony Liguori wrote:
> >>On 09/15/2011 10:38 AM, Gleb Natapov wrote:
> >>>On Thu, Sep 15, 2011 at 10:28:52AM -0500, Anthony Liguori wrote:
>
On 09/15/2011 04:26 PM, Anthony Liguori wrote:
I think this model is the closest to what we have today and is the
most obvious. For something like ne2k, I would expect:
class NE2000 : public Device
{
// ne2k public functions
};
class PCI_NE2000 : public PciDevice
{
// implement PCI func
On 09/15/2011 11:38 AM, Jan Kiszka wrote:
On 2011-09-15 16:11, Anthony Liguori wrote:
An example is a NIC with nvram that stores a mac address. In QOM, the guest
could change the mac address, then a user could hot unplug the device, and then
hot plug the device into a different PCI slot. The p
On 09/15/2011 11:59 AM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 11:33:00AM -0500, Anthony Liguori wrote:
On 09/15/2011 10:38 AM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 10:28:52AM -0500, Anthony Liguori wrote:
On 09/15/2011 09:25 AM, Gleb Natapov wrote:
There is no canonical parent li
On Thu, Sep 15, 2011 at 11:33:00AM -0500, Anthony Liguori wrote:
> On 09/15/2011 10:38 AM, Gleb Natapov wrote:
> >On Thu, Sep 15, 2011 at 10:28:52AM -0500, Anthony Liguori wrote:
> >>On 09/15/2011 09:25 AM, Gleb Natapov wrote:
> >>
> >>There is no canonical parent link. A device may have multiple
On 09/15/2011 10:38 AM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 10:28:52AM -0500, Anthony Liguori wrote:
On 09/15/2011 09:25 AM, Gleb Natapov wrote:
There is no canonical parent link. A device may have multiple (more
or less equivalent) parents.
What should be treated as the "canonical" l
On 2011-09-15 16:11, Anthony Liguori wrote:
> An example is a NIC with nvram that stores a mac address. In QOM, the guest
> could change the mac address, then a user could hot unplug the device, and
> then
> hot plug the device into a different PCI slot. The path is now different but
> the de
On 09/15/2011 05:31 PM, Anthony Liguori wrote:
I think it's in the eye of a beholder. Hold a PCI NE2000 and E1000,
they're clearly both PciDevices, but also they clearly both have PciConnectors.
Write a driver for a PCI and ISA NE2000, and then they're clearly both
NE2000, but also they clearly
On Thu, Sep 15, 2011 at 10:28:52AM -0500, Anthony Liguori wrote:
> On 09/15/2011 09:25 AM, Gleb Natapov wrote:
> >On Thu, Sep 15, 2011 at 04:14:45PM +0200, Paolo Bonzini wrote:
> >>On 09/15/2011 03:57 PM, Anthony Liguori wrote:
> >>>
> >>>void generate_tree(Device *node)
> >>>{
> >>>if (IS_PCI_
On 09/15/2011 09:33 AM, Paolo Bonzini wrote:
On 09/15/2011 04:18 PM, Anthony Liguori wrote:
I think there are two real discussions happening here. One is how to
model and one is what is the right representation of that modelling.
I think Paolo is strongly advocating a non-OO model that uses the
On 09/15/2011 09:25 AM, Gleb Natapov wrote:
On Thu, Sep 15, 2011 at 04:14:45PM +0200, Paolo Bonzini wrote:
On 09/15/2011 03:57 PM, Anthony Liguori wrote:
void generate_tree(Device *node)
{
if (IS_PCI_BUS(node)) {
for (i = 0; i< 32; i++) {
generate_tree(lookup_device(get_p
On 15 September 2011 15:33, Paolo Bonzini wrote:
> I think it's in the eye of a beholder. Hold a PCI NE2000 and E1000, they're
> clearly both PciDevices, but also they clearly both have PciConnectors.
>
> Write a driver for a PCI and ISA NE2000, and then they're clearly both
> NE2000, but also th
On 09/15/2011 04:18 PM, Anthony Liguori wrote:
I think there are two real discussions happening here. One is how to
model and one is what is the right representation of that modelling.
I think Paolo is strongly advocating a non-OO model that uses the
command pattern to establish most of the rel
On Thu, Sep 15, 2011 at 04:14:45PM +0200, Paolo Bonzini wrote:
> On 09/15/2011 03:57 PM, Anthony Liguori wrote:
> >
> >void generate_tree(Device *node)
> >{
> >if (IS_PCI_BUS(node)) {
> > for (i = 0; i < 32; i++) {
> > generate_tree(lookup_device(get_property(node, "slot[%d]", i)
On Thu, Sep 15, 2011 at 08:17:13AM -0500, Anthony Liguori wrote:
> On 09/15/2011 01:31 AM, Gleb Natapov wrote:
> >On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
> >>All device relationships are identified as named properties. A QOM
> >>path name
> >>consists of a named device, fo
On 09/15/2011 08:54 AM, Peter Maydell wrote:
On 15 September 2011 14:35, Paolo Bonzini wrote:
It still holds, for two reasons. 1) The properties will be named
differently for ISA and PCI versions, which is at the very least ugly; 2) if
you want to save the property names for the ISA version, y
On 09/15/2011 03:57 PM, Anthony Liguori wrote:
void generate_tree(Device *node)
{
if (IS_PCI_BUS(node)) {
for (i = 0; i < 32; i++) {
generate_tree(lookup_device(get_property(node, "slot[%d]", i)));
}
} else if (IS_ISA_BUS(node)) {
} else {
/
On 09/15/2011 08:43 AM, Jan Kiszka wrote:
On 2011-09-15 00:11, Anthony Liguori wrote:
On 09/14/2011 04:15 PM, Jan Kiszka wrote:
On 2011-09-14 21:42, Anthony Liguori wrote:
Such names can get fairly long I'm afraid...
A user should never even see these names. A user probably will always
inte
On 09/15/2011 01:31 AM, Gleb Natapov wrote:
On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
All device relationships are identified as named properties. A QOM
path name
consists of a named device, followed by a series of properties which
may or may
not refer to other devices.
On 15 September 2011 14:35, Paolo Bonzini wrote:
> It still holds, for two reasons. 1) The properties will be named
> differently for ISA and PCI versions, which is at the very least ugly; 2) if
> you want to save the property names for the ISA version, you need to
> duplicate the logic in NE2000
On 2011-09-15 00:11, Anthony Liguori wrote:
> On 09/14/2011 04:15 PM, Jan Kiszka wrote:
>> On 2011-09-14 21:42, Anthony Liguori wrote:
Such names can get fairly long I'm afraid...
>>>
>>> A user should never even see these names. A user probably will always
>>> interact with devices via paths
On 09/15/2011 03:26 PM, Anthony Liguori wrote:
class PciConnector : public PciDevice
{
// provides interfaces to register closures which implement
// PCI abstract functions
};
or actually even
class PciConnector : Plug
{
PciBus *bus;
uint8_t config_space[4096];
...
}
The properti
On 09/15/2011 01:47 AM, Paolo Bonzini wrote:
On 09/14/2011 08:04 PM, Anthony Liguori wrote:
The concept of busses are implemented as an
interface that a device implements.
I noticed that you haven't written in the document how to make devices reside on
a particular bus (PCI, ISA, I2C, ...).
T
On 09/15/2011 01:31 AM, Gleb Natapov wrote:
On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
All device relationships are identified as named properties. A QOM
path name
consists of a named device, followed by a series of properties which
may or may
not refer to other devices.
On 09/15/2011 05:49 AM, Stefan Hajnoczi wrote:
On Thu, Sep 15, 2011 at 7:31 AM, Gleb Natapov wrote:
On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
For isa machines:
/isa/ide@0170/drive@0/disk@0
/isa/fdc@03f1/floppy@1
/isa/fdc@03f1/floppy@0
/isa/ide@0170/drive@0/disk@1
Yes, i
On Thu, Sep 15, 2011 at 7:31 AM, Gleb Natapov wrote:
> On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
>> All device relationships are identified as named properties. A QOM
>> path name
>> consists of a named device, followed by a series of properties which
>> may or may
>> not r
On 09/14/2011 08:04 PM, Anthony Liguori wrote:
The concept of busses are implemented as an
interface that a device implements.
I noticed that you haven't written in the document how to make devices
reside on a particular bus (PCI, ISA, I2C, ...).
The three possibilities for this are:
* a de
On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
> All device relationships are identified as named properties. A QOM
> path name
> consists of a named device, followed by a series of properties which
> may or may
> not refer to other devices. For instance, all of the following ar
On 09/14/2011 04:15 PM, Jan Kiszka wrote:
On 2011-09-14 21:42, Anthony Liguori wrote:
Such names can get fairly long I'm afraid...
A user should never even see these names. A user probably will always
interact with devices via paths.
Right.
But will those automatic names be used at all the
On 09/14/2011 03:37 PM, Blue Swirl wrote:
On Wed, Sep 14, 2011 at 8:22 PM, Anthony Liguori wrote:
On 09/14/2011 03:00 PM, Edgar E. Iglesias wrote:
On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
Hi,
I spent a couple hours today writing up some comparisons and an
initial ta
On 2011-09-14 21:42, Anthony Liguori wrote:
>> Such names can get fairly long I'm afraid...
>
> A user should never even see these names. A user probably will always
> interact with devices via paths.
Right.
But will those automatic names be used at all then?
>
> We can also look at doing thi
On Wed, Sep 14, 2011 at 8:22 PM, Anthony Liguori wrote:
> On 09/14/2011 03:00 PM, Edgar E. Iglesias wrote:
>>
>> On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
>>>
>>> Hi,
>>>
>>> I spent a couple hours today writing up some comparisons and an
>>> initial task list for converting
On Wed, Sep 14, 2011 at 03:22:29PM -0500, Anthony Liguori wrote:
> On 09/14/2011 03:00 PM, Edgar E. Iglesias wrote:
> >On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
> >>Hi,
> >>
> >>I spent a couple hours today writing up some comparisons and an
> >>initial task list for converti
On 09/14/2011 03:00 PM, Edgar E. Iglesias wrote:
On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
Hi,
I spent a couple hours today writing up some comparisons and an
initial task list for converting qdev to QOM. The main location of
this is the wiki[1] but I thought I would inl
On Wed, Sep 14, 2011 at 01:04:00PM -0500, Anthony Liguori wrote:
> Hi,
>
> I spent a couple hours today writing up some comparisons and an
> initial task list for converting qdev to QOM. The main location of
> this is the wiki[1] but I thought I would inline it here for easier
> commenting.
>
>
On 09/14/2011 02:30 PM, Jan Kiszka wrote:
On 2011-09-14 20:04, Anthony Liguori wrote:
Hi,
I spent a couple hours today writing up some comparisons and an initial
task list for converting qdev to QOM. The main location of this is the
wiki[1] but I thought I would inline it here for easier comme
On 2011-09-14 20:04, Anthony Liguori wrote:
> Hi,
>
> I spent a couple hours today writing up some comparisons and an initial
> task list for converting qdev to QOM. The main location of this is the
> wiki[1] but I thought I would inline it here for easier commenting.
>
> I decided to do this
On 09/14/2011 01:04 PM, Anthony Liguori wrote:
Hi,
I spent a couple hours today writing up some comparisons and an initial task
list for converting qdev to QOM. The main location of this is the wiki[1] but I
thought I would inline it here for easier commenting.
I decided to do this because I wa
Hi,
I spent a couple hours today writing up some comparisons and an initial
task list for converting qdev to QOM. The main location of this is the
wiki[1] but I thought I would inline it here for easier commenting.
I decided to do this because I wanted to avoid a massively long 00 patch
exp
88 matches
Mail list logo
