From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=35697 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OJWbv-0006im-Kd
	for qemu-devel@nongnu.org; Tue, 01 Jun 2010 14:54:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OJWbp-00027O-Jm
	for qemu-devel@nongnu.org; Tue, 01 Jun 2010 14:54:47 -0400
Received: from mail-iw0-f173.google.com ([209.85.214.173]:56377)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1OJWbp-00027A-C5
	for qemu-devel@nongnu.org; Tue, 01 Jun 2010 14:54:41 -0400
Received: by iwn41 with SMTP id 41so908358iwn.4
	for <qemu-devel@nongnu.org>; Tue, 01 Jun 2010 11:54:40 -0700 (PDT)
Message-ID: <4C055755.7060309@codemonkey.ws>
Date: Tue, 01 Jun 2010 13:54:13 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: [PATCH] qdev: Reject duplicate and anti-social
	device IDs
References: <cover.1274612367.git.jan.kiszka@web.de>	<cover.1274612367.git.jan.kiszka@web.de>	<3715da16813f7cdcb7ec023167a84a94e8a37089.1274612367.git.jan.kiszka@web.de>	<m37hmnjfve.fsf@blackfin.pond.sub.org>
	<4C021ED5.1080703@redhat.com>	<m3r5ks8okg.fsf@blackfin.pond.sub.org>
	<4C038882.3080007@redhat.com>	<m3d3wcrwg7.fsf_-_@blackfin.pond.sub.org>	<20100601100434.380c6ab3@redhat.com>	<m3ljayq0c7.fsf@blackfin.pond.sub.org>	<20100601114920.1afb505a@redhat.com>
	<m3zkzelhxg.fsf@blackfin.pond.sub.org>
In-Reply-To: <m3zkzelhxg.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>, Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>, Blue Swirl <blauwirbel@gmail.com>, Jan Kiszka <jan.kiszka@web.de>, Gerd Hoffmann <kraxel@redhat.com>, Avi Kivity <avi@redhat.com>

On 06/01/2010 01:35 PM, Markus Armbruster wrote:
> Luiz Capitulino<lcapitulino@redhat.com>  writes:
>
>    
>> On Tue, 01 Jun 2010 16:44:24 +0200
>> Markus Armbruster<armbru@redhat.com>  wrote:
>>
>>      
>>> Luiz Capitulino<lcapitulino@redhat.com>  writes:
>>>
>>>        
>>>> On Mon, 31 May 2010 16:13:12 +0200
>>>> Markus Armbruster<armbru@redhat.com>  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