qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH] qdev: Reject duplicate and anti-social devi


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH] qdev: Reject duplicate and anti-social device IDs
Date: Tue, 01 Jun 2010 13:54:13 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4

On 06/01/2010 01:35 PM, Markus Armbruster wrote:
Luiz Capitulino<address@hidden>  writes:

On Tue, 01 Jun 2010 16:44:24 +0200
Markus Armbruster<address@hidden>  wrote:

Luiz Capitulino<address@hidden>  writes:

On Mon, 31 May 2010 16:13:12 +0200
Markus Armbruster<address@hidden>  wrote:

We need Device IDs to be unique and not contain '/' so device tree
nodes can always be unambigously referenced by tree path.

We already have some protection against duplicate IDs, but it got
holes:

* We don't assign IDs to default devices.

* -device and device_add use the ID of a qemu_device_opts.  Which
   rejects duplicate IDs.

* pci_add nic -net use either the ID or option "name" of
   qemu_net_opts.  And there's our hole.  Reproducible with "-net user
   -net nic,id=foo -device lsi,id=foo".
  Two bugs that might not be related to this thread:

   * "id" member is not mandatory for the device_add command:

     { "execute": "device_add", "arguments": { "driver": "e1000" } }
     {"return": {}}
Works as designed.
  What about netdev_add?

  { "execute": "netdev_add", "arguments": { "type": "user" } }
  {"error": {"class": "MissingParameter", "desc": "Parameter 'id' is missing", "data": 
{"name": "id"}}}
The only way to put a netdev to use is connecting it to a NIC with
-device DRIVER,netdev=ID,...  And that requires an ID.

To be honest, I think we should universally require an id parameter or we should auto-assign one and return it during creation.

Implicit/Null ids with QemuOpts are really difficult to work with and it certainly makes device addressing a lot easier.

Regards,

Anthony Liguori





reply via email to

[Prev in Thread] Current Thread [Next in Thread]