On 04.11.24 21:14, Peter Xu wrote:
On Mon, Nov 04, 2024 at 08:51:56PM +0100, David Hildenbrand wrote:
I did that previously, and Peter objected, saying the explicit anon-shared
should not override the implicit shared=off.
Yes, it's better if we can detect that somehow. There should be easy ways to
make that work, so I wouldn't worry about that.
I still think whenever the caller is capable of passing RAM_SHARED flag
into ram_block_add(), we should always respect what's passed in from the
caller, no matter it's a shared / private request.
A major issue with that idea is when !RAM_SHARED, we don't easily know
whether it's because the caller explicitly chose share=off, or if it's
simply the type of ramblock that we don't care (e.g. ROMs).
Agreed. But note that I think ram_block_add() is one level to deep to
handle that.
So besides what I used to suggest on monitoring the four call sites that
can involve those, another simpler (and now I see it even cleaner..) way
could be that we explicitly introduce RAM_PRIVATE. It means whenever we
have things like below in the callers:
Yeah, I called it RAM_FORCE_PRIVATE, but it's the same idea. And simply
calling it RAM_PRIVATE makes sense.
--
Cheers,
David / dhildenb
