From: Peter Xu <peterx@redhat.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>,
qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
philmd@linaro.org
Subject: Re: [PATCH 0/6] Implement memory_region_new_* functions
Date: Wed, 24 Dec 2025 10:36:29 -0500 [thread overview]
Message-ID: <aUwIfYGUXSMOeVUg@x1.local> (raw)
In-Reply-To: <a9a43db6-1a1f-58f1-39c8-06213e9e610e@eik.bme.hu>
On Wed, Dec 24, 2025 at 02:47:20PM +0100, BALATON Zoltan wrote:
> On Wed, 24 Dec 2025, Akihiko Odaki wrote:
> > On 2025/12/24 6:49, BALATON Zoltan wrote:
> > > Our documentation says that memory regions are automatically freed
> > > when the owner dies and the reference counting to do this is also
> > > implemented. However this relies on the QOM free funtion that can only
> > > be set by creating objects with object_new but memory API only
> > > provides constructors that call object_initialize which clears the
> > > free function that prevents QOM to manage the memory region lifetime.
> > > Implement corresponding memory_region_new_* functions that do the same
> > > as the memory_region_init_* functions but create the memory region
> > > with object_new so the lifetime can be automatically managed by QOM as
> > > documented.
> >
> > The documentation explains the existing functions so the discrepancy
> > between them you see should be fixed by updating them, not adding new
> > ones.
>
> Do you mean replacing memory_region_init_* with these memory_region_new_*
> functions? The memory_region_init_* is still useful for embedded memory
> regions that are managed by some other way which is also mentioned in the
> documentation as an alternative so I think both of them are useful for
> different cases. If you mean we need to update docs to refer to
> memory_region_new instead of memory_region_init at some places then I think
> you're right, the docs may also need to be updated or clarified.
To me, it's less convincing to add new APIs without a solid user.
IMHO we can go either (1) leave patch 6 for later, making this series a
cleanup first, or, (2) add users for every new functions introduced, so at
least we know why each of the new functions are introduced and necessary.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2025-12-24 15:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-23 21:49 [PATCH 0/6] Implement memory_region_new_* functions BALATON Zoltan
2025-12-23 21:49 ` [PATCH 1/6] memory: Add internal memory_region_set_ops helper function BALATON Zoltan
2025-12-23 21:49 ` [PATCH 2/6] memory: Factor out common ram region initialization BALATON Zoltan
2025-12-24 15:33 ` Peter Xu
2026-01-25 20:19 ` BALATON Zoltan
2025-12-23 21:49 ` [PATCH 3/6] memory: Factor out more " BALATON Zoltan
2025-12-26 11:31 ` Philippe Mathieu-Daudé
2025-12-23 21:50 ` [PATCH 4/6] memory: Shorten memory_region_init_rom_nomigrate BALATON Zoltan
2025-12-23 21:50 ` [PATCH 5/6] memory: Add internal memory_region_register_ram function BALATON Zoltan
2025-12-26 11:32 ` Philippe Mathieu-Daudé
2025-12-23 21:50 ` [PATCH 6/6] memory: Add memory_region_new* functions BALATON Zoltan
2025-12-24 5:21 ` [PATCH 0/6] Implement memory_region_new_* functions Akihiko Odaki
2025-12-24 13:47 ` BALATON Zoltan
2025-12-24 15:36 ` Peter Xu [this message]
2025-12-25 5:22 ` Akihiko Odaki
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=aUwIfYGUXSMOeVUg@x1.local \
--to=peterx@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=mst@redhat.com \
--cc=odaki@rsg.ci.i.u-tokyo.ac.jp \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.