Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Deprecate k_mem_pool API, remove sys_mem_pool allocator #28611
The k_heap/sys_heap code has been default for a release, so it's time to deprecate the old allocator.
This eliminates the older CONFIG_MEM_POOL_HEAP_BACKEND kconfig, effectively making it true always and removing the ability for applications to request the older pool engine. It then deprecates the older APIs, leaving them in place for internal users as a "Z" API.
There are still a few users of the older API internally that will need cleanup. I'll submit those separately I think, I'm not sure if those are in scope for 2.4 or not:
And there are two places where the underlying sys_heap allocator still gets used:
I'm not clear on how #24358 is a bug, let alone having a release-blocking priority, except as a means of getting this late change into 2.4.0. And I've been told before that stage of release cycle is not a valid reason for rejecting a PR.
But from policy discussion heard at the last TSC regarding criteria for accepting late addition of new boards I need to ask: If a PR like this came three days before release from anybody other than a platinum member company, would people be seriously considering merging it into the release when it passes?
Remove the MEM_POOL_HEAP_BACKEND kconfig, treating it as true always. Now the legacy mem_pool cannot be enabled and all usage uses the k_heap/sys_heap backend. Signed-off-by: Andy Ross <email@example.com>
The sys_mem_pool allocator is a legacy thing. Use the standard heap to reduce code size. Signed-off-by: Andy Ross <firstname.lastname@example.org>
These were implemented in terms of the mem_pool/block API directly (for complicated reasons, the pointers returned from this API may have been allocated from allocators other than the single system heap). Have them use a k_heap instead. Requires a tweak to one test which had hard-coded an assumption about the header size. Signed-off-by: Andy Ross <email@example.com>
The older sys_mem_pool is going away and being replaced by a new allocator. Signed-off-by: Andy Ross <firstname.lastname@example.org>
This code used a sys_mem_pool directly. Use a new-style heap instead to do the same thing. (Note that the usage is a little specious -- it allocates from the heap but doesn't appear to fill or check any data therein, just that the heap memory can be copied from the two memory domains. It's unclear exactly what this is trying to demonstrate and we might want to improve the sample to do something less trivial.) Signed-off-by: Andy Ross <email@example.com>
These two test cases were making whitebox assumptions of both the block header size and memory layout of an old-style k_mem_pool that aren't honored by the k_heap allocator. They aren't testing anything that isn't covered elsewhere. Signed-off-by: Andy Ross <firstname.lastname@example.org>
This test was written to use a TINY system heap (64 bytes) from which it has to allocate on behalf of a userspace process. The change in convention from mem_pool (where the byte count now includes metadata overhead) means it runs out of space. Bump to 192 bytes. Still tiny. Signed-off-by: Andy Ross <email@example.com>
On userspace platforms, this test needs a little bit of kernel heap. The old mem_pool number was specified without metadata overhead (i.e. it reflected 128 bytes of actual data available and the metadata was stored silently somewhere else), where the new heap specifies the size of the contiguous buffer in memory that stores both data and chunk headers, etc... Increase to 256 bytes. Signed-off-by: Andy Ross <firstname.lastname@example.org>
The sys_mem_pool data structure is going away. And this test case didn't actually do much. All it did was create a sys_mem_pool in the app data section (I guess that's the "mem_protect" part?) and validate that it was usable. We have tests for sys_heap to do that already elsewhere anyway; no point in porting. Signed-off-by: Andy Ross <email@example.com>
This tiny header uses non-builtin types but includes no headers that would define them. Recent header motion seems to have exposed a case where this file can get built before its dependencies are included. Add the header directly. Signed-off-by: Andy Ross <firstname.lastname@example.org>
andrewboie left a comment
one nit about an API name change. rest looks fine.
I think we will need to file bugs or otherwise figure out what to do about the remaining uses of z_mem_pool_* inside the kernel so that we can remove all the z_mem_pool code entirely for LTS2, but we have time.