From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org, "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Richard Henderson" <richard.henderson@linaro.org>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Greg Kurz" <groug@kaod.org>
Subject: Re: [PATCH v2 1/5] qemu/qarray.h: introduce QArray
Date: Thu, 30 Sep 2021 15:20:19 +0200 [thread overview]
Message-ID: <12467459.urXsdUxXdL@silver> (raw)
In-Reply-To: <YVSm9s4pUKOzsLqV@redhat.com>
On Mittwoch, 29. September 2021 19:48:38 CEST Daniel P. Berrangé wrote:
> On Wed, Sep 29, 2021 at 07:32:39PM +0200, Christian Schoenebeck wrote:
> > On Dienstag, 28. September 2021 18:41:17 CEST Daniel P. Berrangé wrote:
> > > On Tue, Sep 28, 2021 at 06:23:23PM +0200, Christian Schoenebeck wrote:
> > > > On Dienstag, 28. September 2021 15:04:36 CEST Daniel P. Berrangé
wrote:
> > > > > On Sun, Aug 22, 2021 at 03:16:46PM +0200, Christian Schoenebeck
wrote:
> > [...]
> > > The GLib automatic memory support is explicitly designed to be extendd
> > > with support for application specific types. We already do exactly that
> > > all over QEMU with many calls to G_DEFINE_AUTOPTR_CLEANUP_FUNC(..) to
> > > register functions for free'ing specific types, such that you can
> > > use 'g_autoptr' with them.
> >
> > Ok, just to make sure that I am not missing something here, because really
> > if there is already something that does the job that I simply haven't
> > seen, then I happily drop this QArray code.
>
> I don't believe there is anything that currently addresses this well.
>
> > But AFAICS this G_DEFINE_AUTOPTR_CLEANUP_FUNC() & g_autoptr concept does
> > not have any notion of "size" or "amount", right?
>
> Correct, all it knows is that there's a data type and an associated
> free function.
Ok, thanks for the clarification.
> > So let's say you already have the following type and cleanup function in
> > your existing code:
> >
> > typedef struct MyScalar {
> >
> > int a;
> > char *b;
> >
> > } MyScalar;
> >
> > void myscalar_free(MayScalar *s) {
> >
> > g_free(s->b);
> >
> > }
> >
> > Then if you want to use G_DEFINE_AUTOPTR_CLEANUP_FUNC() for an array on
> > that scalar type, then you still would need to *manually* write
> > additionally a separate type and cleanup function like:
> >
> > typedef struct MyArray {
> >
> > MyScalar *s;
> > int n;
> >
> > };
> >
> > void myarray_free(MyArray *a) {
> >
> > for (int i = 0; i < a->n; ++i) {
> >
> > myscalar_free(a->s[i]);
> >
> > }
> > g_free(a);
> >
> > }
> >
> > Plus you have to manually populate that field 'n' after allocation.
> >
> > Am I wrong?
>
> Yes and no. You can of course manually write all these stuff
> as you describe, but since we expect the array wrappers to be
> needed for more than one type it makes more sense to have
> that all done via macros.
>
> Your patch contains a DECLARE_QARRAY_TYPE and DEFINE_QARRAY_TYPE
> that provide all this reqiured boilerplate code. The essential
> difference that I'm suggesting is that the array struct type emitted
> by the macro is explicitly visible as a concept to calling code such
> that it is used directly used with g_autoptr.
I got that, but your preferred user pattern was this:
DECLARE_QARRAY_TYPE(Foo);
...
g_autoptr(FooArray) foos = foo_array_new(n);
I don't see a portable way to do upper-case to lower-case conversion with the
C preprocessor. So you would end up like this instead:
g_autoptr(FooArray) foos = Foo_array_new(n);
Which does not really fit into common QEMU naming conventions either, does it?
And I can help it, I don't see what's wrong in exposing a regular C-array to
user code. I mean in the Linux kernel for instance it is absolutely normal to
convert from a compound structure to its parent structure. I don't find
anything magical about that and it is simply less code and better readable.
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2021-09-30 13:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-22 13:21 [PATCH v2 0/5] introduce QArray Christian Schoenebeck
2021-08-22 13:16 ` [PATCH v2 1/5] qemu/qarray.h: " Christian Schoenebeck
2021-08-24 8:22 ` Markus Armbruster
2021-08-24 11:51 ` Christian Schoenebeck
2021-08-24 14:45 ` Markus Armbruster
2021-08-24 15:24 ` Christian Schoenebeck
2021-08-24 15:28 ` Christian Schoenebeck
2021-08-25 8:15 ` Markus Armbruster
2021-08-24 11:58 ` Christian Schoenebeck
2021-08-24 14:21 ` Markus Armbruster
2021-09-28 13:04 ` Daniel P. Berrangé
2021-09-28 16:23 ` Christian Schoenebeck
2021-09-28 16:41 ` Daniel P. Berrangé
2021-09-29 17:32 ` Christian Schoenebeck
2021-09-29 17:48 ` Daniel P. Berrangé
2021-09-30 13:20 ` Christian Schoenebeck [this message]
2021-09-30 13:31 ` Daniel P. Berrangé
2021-09-30 13:55 ` Christian Schoenebeck
2021-09-30 14:01 ` Daniel P. Berrangé
2021-09-30 14:17 ` Christian Schoenebeck
2021-08-22 13:17 ` [PATCH v2 2/5] qemu/qarray.h: check scalar type in QARRAY_CREATE() Christian Schoenebeck
2021-08-22 13:17 ` [PATCH v2 3/5] 9pfs: make V9fsString usable via QArray API Christian Schoenebeck
2021-08-22 13:17 ` [PATCH v2 4/5] 9pfs: make V9fsPath " Christian Schoenebeck
2021-08-22 13:17 ` [PATCH v2 5/5] 9pfs: use QArray in v9fs_walk() Christian Schoenebeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12467459.urXsdUxXdL@silver \
--to=qemu_oss@crudebyte.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).