[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/6] qom: introduce TypeInfo name aliases
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [RFC PATCH 0/6] qom: introduce TypeInfo name aliases |
Date: |
Fri, 12 Jan 2018 12:11:19 -0200 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
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
- Re: [Qemu-devel] [RFC PATCH 4/6] arm/xlnx-zynq: use FDT names for the Cadence UART, (continued)
[Qemu-devel] [RFC PATCH 5/6] hw/net/cadence_gem: add FDT names as alias, Philippe Mathieu-Daudé, 2018/01/04
[Qemu-devel] [RFC PATCH 6/6] hw/arm/xlnx-zynq: use FDT names for the Cadence GEM, Philippe Mathieu-Daudé, 2018/01/04
Re: [Qemu-devel] [RFC PATCH 0/6] qom: introduce TypeInfo name aliases, Eduardo Habkost, 2018/01/04