On Sun, 2 Feb 2025, BALATON Zoltan wrote:
On Sat, 1 Feb 2025, Bernhard Beschow wrote:
I've implemented that in my e500-fdt branch which I want to send as an
RFC. I still need to clean it up. Once it's on the list we could make a
plan how to turn it into a p10xx. Would that work for you?
Sure, I can try to test your patches once they are submitted to the list and
rebase my changes on top if they still needed. I've just submitted these so
you can incorporate them in your tree so I have less to rebase but I see you
already have most of these. I'm OK to wait until your tree is cleaned and
submitted but it seems there are a lot of patches so it might take a while. I
don't expect that you can get it merged before the next release. Some of the
patches may need several versions or alternative approaches until they can be
merged. For example I expect problems with allowing ',' in device names as
this is something that was removed before to avoid the need of quoting or
something like that. But I'm not in a hurry as I don't have much free time
for it anyway so only come back to this time to time and it's far from
anything useful yet.
To solve the problem of needing reintroducing ',' in type names and adding
a new subclass for every compatible device variant (which might also be
wasteful if this creates a new type struct for these) maybe you'd have to
attach a string array to classes or type info instead with all the
compatible names and then look for the type to instantiate based on that.
I don't know what the best way would be for that, adding a class property
or adding this array to type? And maybe you need a new funcion to find the
type instead of qdev_try_new().
I don't know how this works but the types seem to be stored in a hash
table so instead of an array of compatible names maybe all that's needed
is to allow adding alternative names for the same type in this type hash
table or add another hash table for those alternative names then types
could be looked up the same way from that by the compatible names without
needing to subclass them multiple times. If these are separated hash
tables then ',' may be allowed in the compatible names table or if it's
the same types table then maybe the names can be encoded in some way to
separate them from normal type names and avoid the need to reintroduce
','. These are just vague ideas but maybe gives you some inspiration for
which way to go to get closer to be able to upstream it.
Regards,
BALATON Zoltan
