deprecate and remove old k_mem_pool / sys_mem_pool APIs

[andrewboie]

We have replaced the mem pool APIs with the new k_heap/sys_heap APIs. We don't need to keep maintaining two APIs for doing the same thing, and should aim to remove the k_mem_pool and sys_mem_pool APIs from the kernel.

The first step is to __deprecate them all, and change any use within Zephyr to use k_heap/sys_heap instead.

The k_pipe_block_put() API will need to be adjusted as it takes a k_mem_block as an argument. I couldn't find any other public APIs which would need to be changed.

[carlescufi]

@andyross and @andrewboie we need this for 2.3.0. Any timeline for a PR?

[andyross]

I was honestly expecting this to wait for a release before deprecation, to reduce churn. The original idea, I thought, was that in 2.3 apps would have the new backend by default but no requirement to move away from the old APIs, then later we'd start moving things away.

Some of this, like the direct mem_pool APIs, is straightforward. Also we could rework k_malloc/k_free in terms of the immediate API and not a double-wrapper. The thread memory pools are coded to the old API but could easily be moved to the new one.

But the old pool scheme has its fingers in other places too, like the k_mem_block abstraction used as a handle, which would be an API change if we want to "fix" that (though for a first cut we could just add a constructor for one from a k_heap+pointer tuple) Also both mailbox and pipe will allocate on the behalf of their users, so they need porting. There are probably others I forget.

The early stuff in that list is easy and can be done this week. The later bits may take some thought and argument.

[andrewboie]

I don't think this should be a high priority bug for 2.3 I think this can wait until 2.4. @carlescufi can you share some details on your reasoning for making this a blocker?

[nashif]

reasoning for making this a blocker?
reasoning is the fact that if we need to deprecate, then it has to happen in 2.3, otherwise might end up with old APIs.

have the new backend by default but no requirement to move away from the old APIs, then later we'd start moving things away.

Ok, if we deprecate this in 2.4, then we should be able to drop legacy in 2.6 (LTS), i think this works fine.

@carlescufi lets move this to 2.4..

[carlescufi]

Agreed, let's move this to 2.4.

[carlescufi]

This should be a bug and be fixed for 2.4. It was already something that had to be fixed for 2.3 and never happened.

@nashif @MaureenHelm do you agree?

[andyross]

OK, sounds good. I'll provide the deprecation patch as soon as I get another spin of the SOF PR up, that one is easy. Note it will end up needing to remove a few tests though. Post-deprecation, there needs to be a new API to convert a heap block to an old-style "mem block" for the oddball APIs that use those.

[andyross]

Consensus in #28611 is that this should be pushed to 2.5

[MaureenHelm]

Consensus in #28611 is that this should be pushed to 2.5

Nevertheless, thank you @andyross for putting together this PR so quickly.

[maksimmasalski]

@andyross Please update milestone, I see 2.4.0

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.