From: Jeff Cody <jcody@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"qemu-devel qemu-devel" <qemu-devel@nongnu.org>,
Programmingkid <programmingkidx@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
jsnow@redhat.com, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] Should we auto-generate IDs?
Date: Thu, 27 Aug 2015 10:18:07 -0400 [thread overview]
Message-ID: <20150827141807.GD31272@localhost.localdomain> (raw)
In-Reply-To: <55DF1828.4000904@redhat.com>
On Thu, Aug 27, 2015 at 08:01:12AM -0600, Eric Blake wrote:
> On 08/27/2015 07:51 AM, Daniel P. Berrange wrote:
> > On Thu, Aug 27, 2015 at 09:39:10AM -0400, Programmingkid wrote:
> >>
> >>> Better still might be fixing things to where we add a global command
> >>> line option that outright fails any attempt to create an unnamed object.
> >>> The option would be off by default for back-compat. But management
> >>> apps like libvirt can turn it on once they are prepared to name every
> >>> object they create (which in turn may imply fixing any remaining
> >>> interfaces that cannot name an object to add in that ability for
> >>> management to pass in a name). Then there would be no unnamed objects,
> >>> no ambiguity, and no need to generate names.
> >>
> >> I do agree with giving every device an ID, but I don't think failing if the user
> >> forgets to give one is necessary. If libvirt doesn't give devices and ID, it
> >> would probably benefit from having QEMU do it for libvirt.
>
> No, you're misunderstanding our argument. The moment there is more than
> one device with an auto-assigned name is the moment that management
> doesn't know which device got which name, so it's better for management
> to pick a name in the first place.
>
> >
> > Libvirt always gives an explicit ID.
>
> Except it doesn't, yet. Libvirt still needs to be taught to name all
> node devices (and I'm slowly trying to work on patches towards that goal).
>
> > It is impossible to rely on QEMU
> > assigning IDs, because there is no reliable way to identify what ID
> > QEMU assigned to each device after the fact. Other management apps
> > would have the same problem, so auto-generated IDs are pretty useless
> > in that respect.
>
> It's not to say that auto-generated names would be useless when running
> qemu manually from the command line, but I agree that management
> probably can't safely rely on auto-generated names, and therefore
> solving the issue of auto-generating names is less important.
>
I agree that the main benefit for auto-generated names in the
immediate timeframe is likely for the user directly invoking QEMU.
This can be painful and very cumbersome for a user opening a QEMU
image with a large backing chain, for instance.
However, at least in the block layer, it may be nice in the future for
QEMU to have essentially unique IDs that it knows unambiguously
identifies each BDS. Perhaps it would be for BDSs that are not created
or specified by libvirt, but done so internally, and exposed later.
Jeff
next prev parent reply other threads:[~2015-08-27 14:18 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-24 18:53 [Qemu-devel] [PATCH] qdev-monitor.c: Add device id generation Programmingkid
2015-08-24 22:21 ` Eric Blake
2015-08-25 12:42 ` Markus Armbruster
2015-08-25 15:25 ` Programmingkid
2015-08-25 15:33 ` Peter Maydell
2015-08-25 15:50 ` Programmingkid
2015-08-25 18:30 ` Markus Armbruster
2015-08-25 19:05 ` Programmingkid
2015-08-25 14:33 ` Programmingkid
2015-08-25 12:38 ` [Qemu-devel] Should we auto-generate IDs? (was: [PATCH] qdev-monitor.c: Add device id generation) Markus Armbruster
2015-08-25 15:15 ` Programmingkid
2015-08-26 14:52 ` Programmingkid
2015-08-26 16:31 ` [Qemu-devel] Should we auto-generate IDs? Markus Armbruster
2015-08-26 17:16 ` Programmingkid
2015-08-26 18:45 ` Peter Maydell
2015-08-26 21:48 ` Programmingkid
2015-08-26 22:08 ` John Snow
2015-08-27 3:40 ` Programmingkid
2015-08-27 5:39 ` Markus Armbruster
2015-08-27 15:39 ` Programmingkid
2015-08-26 17:25 ` Jeff Cody
2015-08-26 17:29 ` Programmingkid
2015-08-26 18:08 ` Jeff Cody
2015-08-26 18:17 ` Programmingkid
2015-08-26 22:01 ` Jeff Cody
2015-08-26 22:04 ` John Snow
2015-08-27 3:26 ` Programmingkid
2015-08-27 3:22 ` Programmingkid
2015-08-27 12:32 ` Jeff Cody
2015-08-27 13:00 ` Eric Blake
2015-08-27 13:39 ` Programmingkid
2015-08-27 13:51 ` Daniel P. Berrange
2015-08-27 14:01 ` Eric Blake
2015-08-27 14:18 ` Jeff Cody [this message]
2015-08-27 14:19 ` Programmingkid
2015-08-27 14:01 ` Programmingkid
2015-08-27 18:59 ` John Snow
2015-08-27 19:20 ` Eric Blake
2015-08-27 13:33 ` Programmingkid
2015-08-27 13:49 ` Daniel P. Berrange
2015-08-27 13:56 ` Programmingkid
2015-08-27 14:02 ` Eric Blake
2015-08-27 14:34 ` Programmingkid
2015-08-27 14:42 ` Daniel P. Berrange
2015-08-27 15:20 ` Programmingkid
2015-08-27 15:40 ` Jeff Cody
2015-08-27 15:58 ` Programmingkid
2015-08-27 16:02 ` Daniel P. Berrange
2015-08-27 16:08 ` Programmingkid
2015-08-27 16:22 ` Daniel P. Berrange
2015-08-27 16:49 ` Programmingkid
2015-08-27 20:15 ` Programmingkid
2015-08-27 19:08 ` Jeff Cody
2015-08-27 19:27 ` Eric Blake
2015-08-27 20:37 ` Jeff Cody
2015-08-27 14:06 ` Daniel P. Berrange
2015-08-27 14:54 ` Programmingkid
2015-08-27 14:07 ` Jeff Cody
2015-08-27 15:13 ` Programmingkid
2015-08-27 15:19 ` Daniel P. Berrange
2015-08-27 15:22 ` Programmingkid
2015-08-27 15:55 ` Daniel P. Berrange
2015-08-27 16:03 ` Programmingkid
2015-08-27 16:06 ` Daniel P. Berrange
2015-08-27 16:08 ` Eric Blake
2015-09-01 12:34 ` Kevin Wolf
2015-09-01 14:18 ` Programmingkid
2015-09-01 14:43 ` Kevin Wolf
2015-09-01 15:55 ` Programmingkid
2015-09-03 14:34 ` Programmingkid
2015-09-03 14:43 ` Jeff Cody
2015-09-03 15:55 ` Programmingkid
2015-09-03 16:12 ` [Qemu-devel] [PATCH v3] qdev-monitor.c: Add device id generation Programmingkid
2015-08-26 17:28 ` [Qemu-devel] Should we auto-generate IDs? (was: [PATCH] qdev-monitor.c: Add device id generation) Daniel P. Berrange
2015-08-26 17:46 ` Programmingkid
2015-08-26 17:53 ` Daniel P. Berrange
2015-08-26 18:01 ` Programmingkid
2015-08-27 13:54 ` Daniel P. Berrange
2015-08-27 14:03 ` Programmingkid
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=20150827141807.GD31272@localhost.localdomain \
--to=jcody@redhat.com \
--cc=afaerber@suse.de \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=programmingkidx@gmail.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).