Re: [PATCH 3/4] crypto: use QOM macros for declaration/definition of secret types

[Eduardo Habkost]

On Fri, Jul 24, 2020 at 10:12:45AM +0100, Daniel P. Berrangé wrote:
> On Thu, Jul 23, 2020 at 02:50:06PM -0400, Eduardo Habkost wrote:
> > On Thu, Jul 23, 2020 at 07:14:09PM +0100, Daniel P. Berrangé wrote:
> > > This introduces the use of the OBJECT_DEFINE and OBJECT_DECLARE macro
> > > families in the secret types, in order to eliminate boilerplate code.
> > > 
> > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > > ---
> > >  crypto/secret.c                 | 24 ++++--------------------
> > >  crypto/secret_common.c          | 32 +++++++++-----------------------
> > >  crypto/secret_keyring.c         | 28 +++++++++-------------------
> > >  include/crypto/secret.h         | 11 ++---------
> > >  include/crypto/secret_common.h  | 13 ++-----------
> > >  include/crypto/secret_keyring.h | 18 ++----------------
> > >  6 files changed, 28 insertions(+), 98 deletions(-)
> > > 
> > 
> > Beautiful.
> > 
> > I wonder how hard it would be to automate this.  I'm assuming
> > Coccinelle won't be able to deal with the macro definitions, but
> > a handwritten conversion script would be really useful for
> > dealing with our 1226 static TypeInfo structs.
> 
> Probably possible to do a reasonably good job with a perl script or
> similar. The code patterns to be replaced are reasonably easy to
> identify with a few regexes.

I've attempted to parse all the TypeInfo structs in the tree.
The data I've extracted is available at:
https://gist.github.com/ehabkost/7a398640492f369685c789ffed0f67aa

It turns out 230 of our 1259 TypeInfo variables don't have
instance_size set and don't have their own struct type defined.

We could:
* Make that a supported use case, and add helper macros that don't
  require MyDevice to be defined;
* Make that not supported, and convert those 230 types automatically; or
* Make that not supported, and convert those 230 types manually.

-- 
Eduardo