On Mon, Jan 08, 2018 at 01:51:22PM +0100, Igor Mammedov wrote: > On Thu, 4 Jan 2018 17:22:03 -0200 > Eduardo Habkost <ehabk...@redhat.com> wrote: > > > On Thu, Jan 04, 2018 at 11:40:40AM -0300, Philippe Mathieu-Daudé wrote: > > > Hi, > > > > > > This RFC series is intended to simplify Flattened Device Tree support, > > > in particular the 'compatible' FDT entry, when Linux names mismatches > > > QEMU ones, but this is the same device modelled. > > > > > > Eventually this might help to remove the QDevAlias qdev_alias_table[] > > > in qdev-monitor.c. > > > > > > > Didn't look closely at the patches yet, but this sounds like a > > nice generic way to replace other alias systems. We have at > > least: > Though it seems easy and trivial, I'm a bit concerned about using > QOM types for the task though. > Also see commit 6acbe4c6f which labels aliases as a bad idea > and says that they are there only for compatibility and shouldn't > be used.
It's true that they are there only for compatibility. But I don't think commit 6acbe4c6f label aliases in general as a bad idea. It just removes a very limited mechanism and make it specific to the only place where it was needed. Now we have at least 5 different places where we do the same thing, so now it might be worth it. But: > So far I agree with that statement, because it introduces > ambiguity in code used internally and more worrying is that > this ambiguity will increase user visible ABI (think of '-device_add > FOO_ALIAS') > that we would need to maintain afterwards. This is a reasonable worry. If aliases exist only for compatibility, they should be restricted to the places where compatibility is really needed. For example: aliases that affect -cpu shouldn't necessarily affect -device. > It would be nice to have unified alias API, but I think it should > be separate one and limited to the same scope (i.e. compat stuff), > and even that won't be easy as different alias impl. we have now > have a different needs. Starting with a separate API would be a good way to understand what are our real needs, before deciding if we really want aliases that affect all object_new() calls. > > wrt this series targeted usage, I'd prefer that object_new/initialize > would use real type names when creating devices as it does currently > > FDT linux guest specific names wouldn't seep into device model > itself. Firmware (FDT or ACPI) should be separate from device > implementation. I agree. The QOM names and FDT names have different expectations and assumptions (the commas added to some type names in this series are one example). Having the QOM type and FDT name match on most cases is nice, but this shouldn't be a requirement. I don't think we should rename user-visible QOM types and change the command-line interface (and require additional compatibility cruft) just to make it more convenient for internal FDT code. > > If really there is need to dynamically scan present devices > and build FDT from result, then probably we should introduce > interface that devices could implement if necessary. > (I was thinking about such possibility for ACPI). But so far > it looked to me as too much overhead for what we do now. > > > > * qdev-monitor.c: qdev_alias_table[] (as mentioned above) > > * chardev/char.c: chardev_alias_table[] > > * target/alpha/cpu.c: alpha_cpu_aliases[] > > * target/ppc/cpu-models.c: ppc_cpu_aliases[] > > * include/hw/boards.h: MachineClass::alias > > > > Probably there are others I couldn't find. > > > > > > > So far this is only a 'proof of concept'. > > > To see how the qtests perform, I only modified 3 devices, 2 used by the > > > Xilinx Zynq machines (Cadence), and the e1000 (used by the PXE test). > > > > > > Regards, > > > > > > Phil. > > > > > > Philippe Mathieu-Daudé (6): > > > qom: introduce TypeInfo name aliases > > > hw/net/e1000: real device name is 'e1000-82540em', 'e1000' is an alias > > > hw/char/cadence_uart: add FDT aliases > > > arm/xlnx-zynq: use FDT names for the Cadence UART > > > hw/net/cadence_gem: add FDT names as alias > > > hw/arm/xlnx-zynq: use FDT names for the Cadence GEM > > > > > > include/qom/object.h | 3 +++ > > > hw/arm/xilinx_zynq.c | 2 ++ > > > hw/arm/xlnx-zynqmp.c | 4 ++-- > > > hw/char/cadence_uart.c | 7 +++++++ > > > hw/net/cadence_gem.c | 6 ++++++ > > > hw/net/e1000.c | 5 ++++- > > > qom/object.c | 18 ++++++++++++++++-- > > > 7 files changed, 40 insertions(+), 5 deletions(-) > > > > > > -- > > > 2.15.1 > > > > > > -- Eduardo
