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.
signature.asc
Description: OpenPGP digital signature
