qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/14] qdev: assign unique names to all devices


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH 00/14] qdev: assign unique names to all devices (part 1)
Date: Mon, 19 Sep 2011 09:41:57 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

Am 16.09.2011 20:03, schrieb Anthony Liguori:
> On 09/16/2011 12:11 PM, Kevin Wolf wrote:
>> Am 16.09.2011 18:54, schrieb Anthony Liguori:
>>> This series just asks the device model developer to come up with a unique 
>>> *when*
>>> they're doing device composition.  Even with a totally path based interface,
>>> this is always going to be a firm requirement.
>>>
>>> I think it may be possible to eliminate required device names by having a 
>>> formal
>>> notion of composition and have the devices store the names of the composed
>>> devices as part of the reference to that device.  You could then have user
>>> created devices use a separate hash table to track the names of those 
>>> devices.
>>>
>>> But, we can't easily do this today.  Having either a fully qualified name 
>>> or a
>>> composition name as part of qdev_create() is the Right Thing IMHO so I think
>>> this is the stepping stone to something more sophisticated.
>>
>> Actually, as I said, I think this naming scheme is already by far too
>> sophisticated. Jan is completely right, there is no point in duplicating
>> paths in a name. Either we assign names only if the user specified one,
>> or we auto-generate a really simple name that doesn't resemble a path,
>> can be easily typed and is actually useful to have in addition to paths
>> (my "#foo-1" suggestion).
> 
> Names have to be relatively stable.  Instantiation ordering should not affect 
> names nor should hotplug.  Otherwise two device models will end up with 
> devices 
> with different names.

But that's what you have paths for. If you introduce name that are meant
to fulfill the same requirements, the only thing you have achieved is
duplication.

This is why I think that _if_ we have names, they should address a
different requirement, like being easy to remember and type. That there
are user-assigned names inclines me to think that this is what they are
meant for. But if they do just the same thing as paths already do, there
is no reason to have them.

> Independent of that, Jan suggested that we could have what's essentially an 
> alias.  This is just a short name (could be in the form '%s-%d' % 
> (class.lower(), object_count).  This alias is just a hash table.  It has 
> nothing 
> to do with the core device model.
> 
> I think what you're really getting at is that you want to be able to do 
> something like 'ide0-hd0' to refer to a device via the command line or HMP.
> 
> I don't really disagree with that either.  But that's a layer on top of the 
> core 
> device model.  We shouldn't push every UI feature we want into the core 
> device 
> model.

Doing it outside the device model certainly works, too. I was just
trying to make your names somewhat useful. If it turns out that we have
no use for them in the device mode, let's use paths for everything and
abandon names.

Kevin



reply via email to

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