All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <ehabkost@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Max Reitz" <mreitz@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day)
Date: Thu, 30 Apr 2020 12:03:12 +0200	[thread overview]
Message-ID: <87tv11e1en.fsf_-_@dusky.pond.sub.org> (raw)
In-Reply-To: <CAFEAcA9-oxkMD-kJ1z12d4K1S_Jaz7Wj6_38Ah7ChSaBfQNkkA@mail.gmail.com> (Peter Maydell's message of "Thu, 30 Apr 2020 10:27:07 +0100")

Peter Maydell <peter.maydell@linaro.org> writes:

> On Thu, 30 Apr 2020 at 08:09, Markus Armbruster <armbru@redhat.com> wrote:
>> Our means to configure onboard devices are weak.  We sidestepped this
>> for isa-fdc by taking it off the board, and thus make -device work.
>
> This seems to be a general dynamic: the x86 pc machine works
> via -device options (or is changed so it can work that way);
> and then people propose dropping/deprecating/etc the config
> options that work with onboard devices, without providing
> clear solutions/instructions on how the command line needs
> to change/etc for the mass of boards which are not the x86
> pc machine and which do have a lot of onboard devices which
> can't be handled via -device.
>
> So my gut reaction to the "we should deprecate -global"
> suggestions in this thread was a bit "here we go again"...
> What works for x86 or even "what is sufficient for libvirt"
> doesn't necessarily cover all the cases.

Such shortsighted proposals have been made, but don't think it's what
we're doing here.

You're 100% right in that we do need to configure onboard devices.
-global is a terrible way to do it, though: it applies to *all* devices
of a kind.  What if the board has more than one?  What if the can add
more?

Taking onboard devices off the board can occasionally sidestep the
issue.  For isa-fdc, we genuinely *wanted* to take the damn thing off,
because all it did for most users was provide them with VENOM.  Not
needing -global for it anymore was just a nice bonus.

Taking onboard devices off just to reduce the device configuration
problem to a solved one, namely -device, may be tempting (it was to me),
but it's too intrusive to be practical at scale.

Adding machine properties that alias onboard device properties is less
intrusive.  The ones I added were still a lot of work.

Configuring onboard devices via machine properties restricts property
access to the ones we added to the machine.  This differs from pluggable
devices, where users can access all properties.

Any better ideas for letting users configure onboard devices?



  reply	other threads:[~2020-04-30 10:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-29 15:28 Failing property setters + hardwired devices + -global = a bad day Markus Armbruster
2020-04-29 15:39 ` Paolo Bonzini
2020-04-29 16:23   ` Eduardo Habkost
2020-04-29 15:57 ` Daniel P. Berrangé
2020-04-30  7:09   ` Markus Armbruster
2020-04-30  9:27     ` Peter Maydell
2020-04-30 10:03       ` Markus Armbruster [this message]
2020-04-30 10:29         ` Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day) Mark Cave-Ayland
2020-04-30 14:11           ` Configuring onboard devices Markus Armbruster
2020-04-30 14:32             ` Mark Cave-Ayland
2020-04-30 15:20               ` Markus Armbruster
2020-04-30 16:56                 ` Mark Cave-Ayland
2020-05-02  5:47                   ` Markus Armbruster
2020-05-03 22:13                     ` Mark Cave-Ayland
2020-05-04 16:30                       ` Eduardo Habkost
2020-04-30 10:34         ` Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day) Daniel P. Berrangé
2020-04-30 10:45           ` Peter Maydell
2020-04-30 10:53             ` Daniel P. Berrangé
2020-04-30 14:38               ` Configuring onboard devices Markus Armbruster
2020-04-30 10:54             ` Configuring onboard devices (was: Failing property setters + hardwired devices + -global = a bad day) Mark Cave-Ayland
2020-04-30 14:27           ` Configuring onboard devices Markus Armbruster

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=87tv11e1en.fsf_-_@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mreitz@redhat.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 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.