On 03.09.25 18:12, Thierry Reding wrote:
On Tue, Sep 02, 2025 at 09:04:24PM +0200, David Hildenbrand wrote:
+>> +struct cma *__init cma_create(phys_addr_t base, phys_addr_t size,
+ unsigned int order_per_bit, const char *name)
+{
+ struct cma *cma;
+ int ret;
+
+ ret = cma_check_memory(base, size);
+ if (ret < 0)
+ return ERR_PTR(ret);
+
+ cma = kzalloc(sizeof(*cma), GFP_KERNEL);
+ if (!cma)
+ return ERR_PTR(-ENOMEM);
+
+ cma_init_area(cma, name, size, order_per_bit);
+ cma->ranges[0].base_pfn = PFN_DOWN(base);
+ cma->ranges[0].early_pfn = PFN_DOWN(base);
+ cma->ranges[0].count = cma->count;
+ cma->nranges = 1;
+
+ cma_activate_area(cma);
+
+ return cma;
+}
+
+void cma_free(struct cma *cma)
+{
+ kfree(cma);
+}
--
2.50.0
I agree that supporting dynamic CMA areas would be good. However, by
doing it like this, these CMA areas are invisible to the rest of the
system. E.g. cma_for_each_area() does not know about them. It seems a
bit inconsistent that there will now be some areas that are globally
known, and some that are not.
Yeah, I'm not a fan of that.
What is the big problem we are trying to solve here? Why do they have to be
dynamic, why do they even have to support freeing?
Freeing isn't necessarily something that I've needed. It just seemed
like there wasn't really a good reason not to support it. The current
implementation here is not sufficient, though, because we'd need to
properly undo everything that cma_activate_area() does. I think the
cleanup: block in cma_activate_area() is probably sufficient.
The problem that I'm trying to solve is that currently, depending on the
use-case the kernel configuration needs to be changed and the kernel
rebuilt in order to support it. However there doesn't seem to be a good
technical reason for that limitation. The only reason it is this way
seems to be that, well, it's always been this way.
Right, and we can just dynamically grow the array, keep them in a list etc.
--
Cheers
David / dhildenb
