On 17 February 2017 at 17:47, Herb Peyerl <hpey...@beer.org> wrote: > On Feb 17, 2017, at 10:17 AM, Peter Maydell <peter.mayd...@linaro.org> 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