qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or I


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] sysbus: add no_user for devices using mmio or IRQ or GPIO
Date: Thu, 7 Mar 2013 18:00:17 +0800

On 7 March 2013 16:48, Markus Armbruster <address@hidden> wrote:
> Can we make some progress towards something that makes more sense?
>
> First step: reasons for marking a device no_user.
>
> From a user point of view, I think there's just one: -device/device_add
> cannot possibly result in a working device.  Coherent enough semantics
> for no_user, in my opinion, but I readily concede it's not particularly
> useful for maintaining it as infrastructure and device models evolve.

Ideally it would be nice to move to a model where the error message
was "the device you've created has some required connections which
haven't been wired up", and then for some devices you'd always get
that error [until we implemented syntax for doing the wiring] and
for some you'd only get it if you messed up the command line switches.

> For that, we need to drill down into reasons for "cannot possibly work".
> Here are two, please add more:
>
> * Can't make required connections

> * Resource collision with board
>
>   The device must connect to some fixed resource, but the board already
>   connects something to it.  Without no_user, this should result in an
>   error message of sorts, which is much better than the silent breakage
>   above.  Whether the message makes any sense to the user is a different
>   question.

Do we have any concrete examples of this? I don't think devices should
be making connections to resources themselves. If the only things wiring
up devices are (a) the board models and (b) anything the user says on
the command line, then the conflict only happens if the user says
-device foo,bar=0x42 and bar 0x42 is in use; in that case the message
will make sense to them.

I think a third case for no-user is "this device is actually an
abstract base class" (eg arm_gic_common), which we could deal with
by checking the TypeInfo instead.

Case four: "we really don't expect anybody to be trying to wire this
up dynamically", which would apply to things like the on-cpu peripherals
for some ARM cores. There it is really just an attempt at being friendly
by cutting down the length of the devices list.

Speaking of friendlyness, it might be helpful if the '-devices help'
list was somehow more structured than a single long list and if
more devices had description text?

>>                          [and I don't think "this device
>> can be added via the monitor but not the command line"
>> counts as consistent or coherent...]
>
> no_user applies equally to -device and device_add.

In the codebase as it stands, it applies only to -device.
I agree that we should be consistent here, which we could do
by applying Christian's patch or some variation to make device_add
honour no_user. (Or by removing no_user altogether :-))

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]