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(-)
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. 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
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: * 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
On Thu, 4 Jan 2018 17:22:03 -0200 Eduardo Habkost <ehabkost@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. 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. 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. 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. 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 > > >
Hi Igor,
On 01/08/2018 09:51 AM, Igor Mammedov wrote:
[...]
> 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.
> 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.
> 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.
>
> 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.
Good point.
> 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.
I see, I thought about something similar but TypeInfo.aliases was way
too simple to not try this series first.
What about adding a INTERFACE_FDT_DEVICE type (InterfaceInfo) and let
the FDT devices implement something such:
typedef struct {
/*< private >*/
InterfaceClass parent_class;
DeviceClass parent_class;
/*< public >*/
bool (*is_alias)(FDTDeviceIf *dev, const char *name);
bool (*set_prop...)(FDTDeviceIf *dev, const char *property, ...);
const void *(*get_prop)(FDTDeviceIf *dev, const char *property);
};
Regards,
Phil.
On Mon, Jan 08, 2018 at 11:10:37AM -0300, Philippe Mathieu-Daudé wrote:
> Hi Igor,
>
> On 01/08/2018 09:51 AM, Igor Mammedov wrote:
> [...]
> > 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.
> > 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.
> > 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.
> >
> > 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.
>
> Good point.
>
> > 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.
>
> I see, I thought about something similar but TypeInfo.aliases was way
> too simple to not try this series first.
>
> What about adding a INTERFACE_FDT_DEVICE type (InterfaceInfo) and let
> the FDT devices implement something such:
>
> typedef struct {
> /*< private >*/
> InterfaceClass parent_class;
> DeviceClass parent_class;
> /*< public >*/
> bool (*is_alias)(FDTDeviceIf *dev, const char *name);
> bool (*set_prop...)(FDTDeviceIf *dev, const char *property, ...);
> const void *(*get_prop)(FDTDeviceIf *dev, const char *property);
An interface common to FDT devices probably make sense, but I
don't know if the one you suggest above makes sense or not (a
description of each method would be useful to understand what
exactly they would do).
--
Eduardo
On Mon, Jan 08, 2018 at 01:51:22PM +0100, Igor Mammedov wrote: > On Thu, 4 Jan 2018 17:22:03 -0200 > Eduardo Habkost <ehabkost@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
© 2016 - 2025 Red Hat, Inc.