[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] ide: Get rid of IDEDrive struct
From: |
Peter Maydell |
Subject: |
Re: [PATCH] ide: Get rid of IDEDrive struct |
Date: |
Thu, 6 Aug 2020 09:58:10 +0100 |
On Wed, 5 Aug 2020 at 23:14, Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Wed, Aug 05, 2020 at 09:41:25PM +0100, Peter Maydell wrote:
> > This is one of those areas where this change works and reduces
> > amount of code, but on the other hand it means the QOM type
> > doesn't follow the common pattern for a leaf type of:
> > * it has a struct
> > * it has cast macros that cast to that struct
> > * the typeinfo instance_size is the size of that struct
> > (it wasn't exactly following this pattern before, of course).
>
> Is this really a pattern that exists and we want to follow?
> I don't see why that pattern would be useful for simple leaf
> types.
Most leaf types need this. Consider a simple device type
like TYPE_CMSDK_APB_UART. It has a TYPE_* name so that
users of it can instantiate it; it has a CMSDKAPBUART struct
that holds all the device state; it has the CMSDK_APB_UART()
cast macro so that code that gets a Device* or Object* can
get at the struct. Leaf types like ide-hd which have no
actual state of their own are I think the less common case:
most leaf types do have at least some member variables.
As Markus says, we can have a couple of standard patterns
if we want to (as we do for the class-macro conventions);
I just wanted to explain that lots of leaf types work the
way I outline above.
thanks
-- PMM