From: Kevin Wolf <kwolf@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
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 [thread overview]
Message-ID: <4E76F245.60700@redhat.com> (raw)
In-Reply-To: <4E738F65.3050403@codemonkey.ws>
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
next prev parent reply other threads:[~2011-09-19 7:39 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-16 16:00 [Qemu-devel] [PATCH 00/14] qdev: assign unique names to all devices (part 1) Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 01/14] apic: rename apic.id -> apic.index Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 02/14] qdev: enforce that no devices overload the id property Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 03/14] qdev: push id into qdev_create calls Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 04/14] qdev: take ownership of id pointer Anthony Liguori
2011-09-19 7:34 ` Gerd Hoffmann
2011-09-19 16:27 ` Anthony Liguori
2011-09-20 6:36 ` Gerd Hoffmann
2011-09-20 13:04 ` Anthony Liguori
2011-09-20 13:21 ` Gerd Hoffmann
2011-09-20 13:55 ` Anthony Liguori
2011-09-20 14:11 ` Gerd Hoffmann
2011-09-16 16:00 ` [Qemu-devel] [PATCH 05/14] qdev: remove opts pointer tracking Anthony Liguori
2011-09-19 7:35 ` Gerd Hoffmann
2011-09-16 16:00 ` [Qemu-devel] [PATCH 06/14] qdev: add ability to do QOM-style derived naming Anthony Liguori
2011-09-17 18:39 ` Blue Swirl
2011-09-16 16:00 ` [Qemu-devel] [PATCH 07/14] sysbus: add an id argument to sysbus_create_simple() Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 08/14] sysbus: make create_varargs take an id Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 09/14] fw_cfg: add name to global fw_cfg device Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 10/14] isa: add name parameter to device creation Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 11/14] pci: obtain devfn before initializing the device Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 12/14] pci: give pci devices a default name Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 13/14] ide: give IDE drives a default name in qdev Anthony Liguori
2011-09-16 16:00 ` [Qemu-devel] [PATCH 14/14] pc: assign names to machine created devices Anthony Liguori
2011-09-16 16:22 ` [Qemu-devel] [PATCH 00/14] qdev: assign unique names to all devices (part 1) Anthony Liguori
2011-09-16 16:48 ` Jan Kiszka
2011-09-16 16:54 ` Anthony Liguori
2011-09-16 17:03 ` Jan Kiszka
2011-09-16 18:06 ` Anthony Liguori
2011-09-16 17:11 ` Kevin Wolf
2011-09-16 18:03 ` Anthony Liguori
2011-09-19 7:26 ` Jan Kiszka
2011-09-19 14:05 ` Anthony Liguori
2011-09-19 14:24 ` Kevin Wolf
2011-09-20 8:32 ` Jan Kiszka
2011-09-19 7:41 ` Kevin Wolf [this message]
2011-09-16 18:21 ` Anthony Liguori
2011-09-19 7:34 ` Jan Kiszka
2011-09-17 18:41 ` Blue Swirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E76F245.60700@redhat.com \
--to=kwolf@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=armbru@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).