Re: [Qemu-discuss] quick pointer on adding a new chardev

[Peter Maydell]

On 17 February 2017 at 17:47, Herb Peyerl <address@hidden> wrote:
> On Feb 17, 2017, at 10:17 AM, Peter Maydell <address@hidden> wrote:
>> If your device is already present then you don't want to
>> try to use -device (which would be attempting to add
>> a second instance of it to the system).
>
> so then, as you say, I should be using ‘-global’ somehow instead
> to bind it to a ‘-chardev socket’  and I don’t need to
> “DEFINE_PROP_CHR()” and so forth?

-global sets properties for already-existing objects in the
system, so you still need a property to be defined on
your object if you want to do that. If you're using
the get_next_serial route then you don't, because you
get the chardev from that function rather than via a
property being set.

> I apparently don’t understand this as well as I thought I did.

-device and -object are both command line switches for
"create me one of these and set its properties like this".

What you're looking at here is that QEMU has a "modern"
view of how to build emulated systems which is strongly
object based and (ideally) completely command line configurable,
but it's layered on top of the "legacy" view of things
(and legacy codebase!) which has lots of hardcoded devices
that get created by default, and command line options
which directly provide specific kinds of information.
This means that many things you might want to do come with two
different APIs in QEMU for them (in this case properties
vs using get_next_serial or equivalently looking in
the right element of the serial_hds[] array), and also
with different command line interfaces (manually creating
chardev objects and wiring them up via id=, versus
the old -serial shorthand option). Sometimes the shorthand
command line interface is just syntactic sugar for a longer
new-style version, but sometimes it isn't (because the
legacy semantics aren't exactly expressible in the new style).

Unfortunately we can't get rid of the legacy view
entirely, because we can't break backwards compatibility
(for commandlines, migration, and so on) in the way
that we'd need to do for this. Also it's a big job and
even cleanup we can do tends to move slowly; the removal of
the get_next_serial API is an example of this (it's a bad API
because it means that which order serial devices are created
by the board is important because the first one created
gets the first -serial argument, and so on; instead it's
better, even for legacy-style devices, to explicitly use
serial_hds[0] for the first -serial device and so on,
and ideally for this to be done by board-level code which
then in C code sets a chardev property on a fully
new-object-style device to the value of serial_hds[0],
rather than the device grabbing the next serial device itself.)
The process of conversion is further advanced for user
pluggable devices (like ISA or PCI bus devices) than it is
for devices that are hardwired into board models. (In particular
you can't create a non-pluggable device on the command line
because there is no syntax to say "and wire my IRQ line up
to this and map my registers at this address".)

thanks
-- PMM