Re: [PATCH] ide: Get rid of IDEDrive struct

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, Aug 06, 2020 at 07:58:06AM +0200, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
> 
> > On Wed, Aug 05, 2020 at 09:41:25PM +0100, Peter Maydell wrote:
> >> On Wed, 5 Aug 2020 at 20:49, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >> >
> >> > The struct had a single field (IDEDevice dev), and is only used
> >> > in the QOM type declarations and property lists.  We can simply
> >> > use the IDEDevice struct directly instead.
> >> >
> >> > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> >> > @@ -327,7 +323,6 @@ static void ide_hd_class_init(ObjectClass *klass, void *data)
> >> >  static const TypeInfo ide_hd_info = {
> >> >      .name          = "ide-hd",
> >> >      .parent        = TYPE_IDE_DEVICE,
> >> > -    .instance_size = sizeof(IDEDrive),
> >> >      .class_init    = ide_hd_class_init,
> >> >  };
> >> 
> >> 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.
> 
> I think the pattern exists, but we deviate from it in quite a few
> places, probably just because it's so much boilerplate.
> 
> Related: Daniel's "[PATCH 0/4] qom: reduce boilerplate required for
> declaring and defining objects".  Perhaps Daniel has an opinion on
> taking shortcuts with leaf types.

I think following a consistent pattern everywhere is important,
because people look at existing code to guide their new code.
The boilerplate pain is very real, but I think my patch series
you point to will reduce the burden sufficiently that the kind
of optimization proposed here is not required.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|