From: Gleb Natapov <gleb@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 6/6] qdev: Generate IDs for anonymous devices
Date: Wed, 7 Sep 2011 13:34:23 +0300 [thread overview]
Message-ID: <20110907103423.GN15275@redhat.com> (raw)
In-Reply-To: <4E67470B.1090107@siemens.com>
On Wed, Sep 07, 2011 at 12:27:23PM +0200, Jan Kiszka wrote:
> On 2011-09-07 11:50, Gleb Natapov wrote:
> > On Wed, Aug 31, 2011 at 08:31:26PM +0200, Jan Kiszka wrote:
> >> On 2011-08-29 23:19, Anthony Liguori wrote:
> >>> On 08/29/2011 03:56 PM, Jan Kiszka wrote:
> >>>> On 2011-08-29 21:23, Anthony Liguori wrote:
> >>>>> On 08/26/2011 09:48 AM, Jan Kiszka wrote:
> >>>>>> In order to address devices for that the user forgot or is even unable
> >>>>>> (no_user) to provide an ID, assign an automatically generated one. Such
> >>>>>> IDs have the format #<number>, thus are outside the name space availing
> >>>>>> to users. Don't use them for bus naming to avoid any other user-visible
> >>>>>> change.
> >>>>>
> >>>>> I don't think this is a very nice approach. Why not eliminate anonymous
> >>>>> devices entirely and use a parent derived name for devices that are not
> >>>>> created by the user?
> >>>>
> >>>> This eliminates anonymous devices completely. So I guess you are asking
> >>>> for a different naming scheme, something like<parent-id>.child#<no>
> >>>> e.g.? Well, we would end up with fairly long names when a complete
> >>>> hierarchy is anonymous. What would be the benefit?
> >>>
> >>> No, I'm saying that whenever a device is created, it should be given a
> >>> non-random name. IOW, the names of these devices should be stable.
> >>>
> >>>> I'm really just looking for some simple, temporary workaround without
> >>>> touching the existing fragile naming scheme. What we really need is full
> >>>> path addressing, but that without preserving all the legacy.
> >>>
> >>> Yeah, I understand, and I hesitated making any grander suggestions here,
> >>> but I'm not sure how much work it would be to just remove any caller
> >>> that passes NULL for ID and replace it with something more meaningful. I
> >>> think that's a helpful clean up long term no matter what.
> >>
> >> That won't solve the problem of finding a unique device name. If we want
> >> to derive it from stable device properties (bus addresses etc.), we
> >> first of all have to define them for all types of devices. And that's
> >> basically were the discussion exploded last year IIRC.
> >>
> > Why not use the OpenFirmware naming that we already have for some
> > devices instead of inventing something new?
>
> Because I do not want to establish any path names before QOM conversion
> (including potential device reorganization) has been started.
In theory device paths are dictated by HW topology, not today's flavor of
QEMU object model.
> Specifically as I do not need naming for "some" devices, but for all.
>
It can be extended. We already have three types of device naming. One is
used in qdev, another is used for migration and yet another one for
passing device names to firmware. We should converge to a single one :)
--
Gleb.
next prev parent reply other threads:[~2011-09-07 10:34 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-26 14:48 [Qemu-devel] [PATCH 0/6] Device state visualization reloaded Jan Kiszka
2011-08-26 14:48 ` [Qemu-devel] [PATCH 1/6] monitor: return length of printed string via monitor_[v]printf Jan Kiszka
2011-08-26 14:48 ` [Qemu-devel] [PATCH 2/6] Add base64 encoder/decoder Jan Kiszka
2011-08-26 15:21 ` Peter Maydell
2011-08-26 15:23 ` Jan Kiszka
2011-08-26 15:47 ` Jan Kiszka
2011-08-26 18:02 ` Jan Kiszka
2011-09-02 17:22 ` Luiz Capitulino
2011-09-05 13:55 ` [Qemu-devel] required glib version? " Gerd Hoffmann
2011-08-26 14:48 ` [Qemu-devel] [PATCH 3/6] QMP: Reserve namespace for complex object classes Jan Kiszka
2011-09-02 17:23 ` Luiz Capitulino
2011-09-02 17:47 ` Jan Kiszka
2011-09-02 18:02 ` Anthony Liguori
2011-08-26 14:48 ` [Qemu-devel] [PATCH 4/6] QMP: Add QBuffer Jan Kiszka
2011-08-26 18:23 ` [Qemu-devel] [PATCH v2 " Jan Kiszka
2011-08-26 14:48 ` [Qemu-devel] [PATCH 5/6] monitor: Add basic device state visualization Jan Kiszka
2011-08-26 14:48 ` [Qemu-devel] [PATCH 6/6] qdev: Generate IDs for anonymous devices Jan Kiszka
2011-08-29 19:23 ` Anthony Liguori
2011-08-29 20:56 ` Jan Kiszka
2011-08-29 21:19 ` Anthony Liguori
2011-08-31 18:31 ` Jan Kiszka
2011-09-07 9:50 ` Gleb Natapov
2011-09-07 10:27 ` Jan Kiszka
2011-09-07 10:34 ` Gleb Natapov [this message]
2011-09-07 10:58 ` Jan Kiszka
2011-08-29 19:22 ` [Qemu-devel] [PATCH 0/6] Device state visualization reloaded Anthony Liguori
2011-08-29 20:54 ` Jan Kiszka
2011-09-02 17:27 ` Luiz Capitulino
2011-09-06 14:48 ` Michael S. Tsirkin
2011-09-06 15:45 ` Jan Kiszka
2011-09-06 15:51 ` Anthony Liguori
2011-09-06 16:05 ` Jan Kiszka
2011-09-06 16:08 ` Anthony Liguori
2011-09-06 16:33 ` Jan Kiszka
2011-09-06 16:09 ` Michael S. Tsirkin
2011-09-06 16:28 ` Anthony Liguori
2011-09-06 17:05 ` Michael S. Tsirkin
2011-09-07 9:37 ` Kevin Wolf
2011-09-07 13:06 ` Michael S. Tsirkin
2011-09-07 13:13 ` Jan Kiszka
2011-09-07 13:17 ` Michael S. Tsirkin
2011-09-07 13:23 ` Anthony Liguori
2011-09-07 13:29 ` Jan Kiszka
2011-09-07 13:33 ` Michael S. Tsirkin
2011-09-06 16:29 ` Jan Kiszka
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=20110907103423.GN15275@redhat.com \
--to=gleb@redhat.com \
--cc=armbru@redhat.com \
--cc=jan.kiszka@siemens.com \
--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).