All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Markus Armbruster <armbru@redhat.com>,
	QEMU Trivial <qemu-trivial@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH] osdep.h: Add doc comment for qemu_get_thread_id()
Date: Thu, 30 Jul 2020 17:40:23 +0100	[thread overview]
Message-ID: <20200730164023.GQ3477223@redhat.com> (raw)
In-Reply-To: <4d2cba04-04d8-9b82-562f-acb84b6010d2@redhat.com>

On Thu, Jul 30, 2020 at 11:24:51AM -0500, Eric Blake wrote:
> On 7/30/20 10:59 AM, Daniel P. Berrangé wrote:
> 
> > > Well, I suspect that management-layer code currently has
> > > gone for "assume we're always running on Linux" and was
> > > written by people who knew they were getting a Linux tid...
> > 
> > Yes, on the libvirt side, the functionality that relies on thread_is is
> > only compiled on Linux. If someone wants to use it on other OS, they'll
> > have to provide an impl using their platforms equivalent of
> > sched_setaffinity and friends since none of this stuff is standardized
> > across OS.
> > 
> > 
> > > > The PID is quite unlikely to be "an OS-specific identifier of the
> > > > current thread".  Shouldn't we fail instead of lie when we don't know
> > > > how to compute the truth?
> > > 
> > > Yeah, I think the default codepath is pretty bogus too. Should
> > > the QMP functions have a mechanism for saying "we don't know
> > > a thread-id on this platform" ?
> > 
> > Thread_id should be optional and thus not filled in if we
> > can't provide a sensible value. Unfortunately we made it
> > mandatory in QMP.
> 
> Normally, converting a mandatory output value to optional is a
> back-compatibility risk (we could break apps that depended on it being
> present).  But if the only apps that depended on it being present are
> compiled on Linux, where the member will actually be present, I think that
> changing the schema to make it optional for non-Linux platforms won't be a
> back-compatibility nightmare (but we will have to be careful in our
> documentation).

FWIW, libvirt treats it as mandatory for query-iothreads, but optional
for query-cpus because it was missing in some older QEMU versions
entirely.

Libvirt explicitly only supports macOS, Linux and FreeBSD, so if those
platforms all report a value, libvirt won't care if you make it optional
and omit it for other platforms.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



WARNING: multiple messages have this Message-ID (diff)
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>,
	Peter Maydell <peter.maydell@linaro.org>,
	Markus Armbruster <armbru@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [PATCH] osdep.h: Add doc comment for qemu_get_thread_id()
Date: Thu, 30 Jul 2020 17:40:23 +0100	[thread overview]
Message-ID: <20200730164023.GQ3477223@redhat.com> (raw)
In-Reply-To: <4d2cba04-04d8-9b82-562f-acb84b6010d2@redhat.com>

On Thu, Jul 30, 2020 at 11:24:51AM -0500, Eric Blake wrote:
> On 7/30/20 10:59 AM, Daniel P. Berrangé wrote:
> 
> > > Well, I suspect that management-layer code currently has
> > > gone for "assume we're always running on Linux" and was
> > > written by people who knew they were getting a Linux tid...
> > 
> > Yes, on the libvirt side, the functionality that relies on thread_is is
> > only compiled on Linux. If someone wants to use it on other OS, they'll
> > have to provide an impl using their platforms equivalent of
> > sched_setaffinity and friends since none of this stuff is standardized
> > across OS.
> > 
> > 
> > > > The PID is quite unlikely to be "an OS-specific identifier of the
> > > > current thread".  Shouldn't we fail instead of lie when we don't know
> > > > how to compute the truth?
> > > 
> > > Yeah, I think the default codepath is pretty bogus too. Should
> > > the QMP functions have a mechanism for saying "we don't know
> > > a thread-id on this platform" ?
> > 
> > Thread_id should be optional and thus not filled in if we
> > can't provide a sensible value. Unfortunately we made it
> > mandatory in QMP.
> 
> Normally, converting a mandatory output value to optional is a
> back-compatibility risk (we could break apps that depended on it being
> present).  But if the only apps that depended on it being present are
> compiled on Linux, where the member will actually be present, I think that
> changing the schema to make it optional for non-Linux platforms won't be a
> back-compatibility nightmare (but we will have to be careful in our
> documentation).

FWIW, libvirt treats it as mandatory for query-iothreads, but optional
for query-cpus because it was missing in some older QEMU versions
entirely.

Libvirt explicitly only supports macOS, Linux and FreeBSD, so if those
platforms all report a value, libvirt won't care if you make it optional
and omit it for other platforms.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2020-07-30 16:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-16 15:41 [PATCH] osdep.h: Add doc comment for qemu_get_thread_id() Peter Maydell
2020-07-28 15:02 ` Peter Maydell
2020-07-28 15:02   ` Peter Maydell
2020-07-28 15:16 ` Eric Blake
2020-07-28 15:25   ` Peter Maydell
2020-07-28 15:25     ` Peter Maydell
2020-07-30 15:10     ` Markus Armbruster
2020-07-30 15:10       ` Markus Armbruster
2020-07-30 15:52       ` Peter Maydell
2020-07-30 15:52         ` Peter Maydell
2020-07-30 15:59         ` Daniel P. Berrangé
2020-07-30 15:59           ` Daniel P. Berrangé
2020-07-30 16:24           ` Eric Blake
2020-07-30 16:24             ` Eric Blake
2020-07-30 16:40             ` Daniel P. Berrangé [this message]
2020-07-30 16:40               ` Daniel P. Berrangé
2020-07-31  7:44             ` Markus Armbruster
2020-07-31  7:44               ` Markus Armbruster
2020-07-31 13:46               ` Eric Blake
2020-07-31 13:46                 ` Eric Blake
2020-07-31 13:51                 ` Daniel P. Berrangé
2020-07-31 13:51                   ` Daniel P. Berrangé
  -- strict thread matches above, loose matches on Subject: below --
2020-10-12 15:33 [PATCH 00/10] target/arm: Various v8.1M minor features Peter Maydell
2020-10-12 15:33 ` [PATCH] osdep.h: Add doc comment for qemu_get_thread_id() Peter Maydell

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=20200730164023.GQ3477223@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eblake@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.