Re: [PATCH 01/14] sm501: replace PROP_PTR with PROP_LINK

[Peter Maydell]

On Fri, 18 Oct 2019 at 17:36, Marc-André Lureau
<address@hidden> wrote:
> On Fri, Oct 18, 2019 at 6:22 PM Peter Maydell <address@hidden> wrote:
> > So I think the right fix here is to properly QOMify the
> > code which is not QOMified, ie hw/char/serial.c, in a
> > way that means that the various "memory mapped 16650-ish
> > devices" we have can use it and can define a
> > TYPE_CHARDEV property.
>
> I see, I can look at that.

It would certainly be a nice cleanup/refactoring to have;
it's likely quite painful though as so many things use
serial_mm_init, many of them not properly QOMified themselves;
and because SerialState is used by x86 it's likely to be
tricky to handle for migration-compat reasons.

> > In general I think our uses of PROP_PTR are code smells
> > that indicate places where we have not properly converted
> > code over to the general approach that the QOM/qdev
> > design desires; but we should be getting rid of PROP_PTR
> > by actually doing all those (difficult) conversions.
>
> I think all user_creatable = false are smelly in that regard.

I dunno, I tend to think that "not user creatable" is the
default state of things. Almost all devices aren't user
creatable, because they need to be wired up and put at
suitable addresses and IRQ lines. Pluggable devices like
PCI, ISA, etc are the weird exceptions that are usefully
user-creatable.

> > Merely removing PROP_PTR itself by rephrasing the dubious
> > inter-device connections in a way that makes them harder
> > to grep for doesn't seem to me to be necessarily worth
>
> grep for user_creatable = false
>
> > doing. Is the existence of PROP_PTR getting in your way
> > for a change you want to make ?
>
> Yes, I am looking at improving the qdev vs object and class vs
> instance properties. I have a larger series of wip refactoring. This
> initial series is preliminary cleanup that would help.

OK, that makes sense. I'll have a look through the series
again; if we don't want to do the nice cleanups now then
probably these changes are ok, possibly with some TODO
comments noting what we ideally ought to do instead.

thanks
-- PMM