kernel: Add k_mem_pool compatibility layer on top of k_heap

Add a shim layer implementing the legacy k_mem_pool APIs backed by a
k_heap instead of the original implementation.

Signed-off-by: Andy Ross <andrew.j.ross@intel.com>

include/kernel.h

@@ -4692,6 +4692,14 @@ void k_heap_free(struct k_heap *h, void *mem);
  * If the pool is to be accessed outside the module where it is defined, it
  * can be declared via
  *
+ * @note When CONFIG_MEM_POOL_HEAP_BACKEND is enabled, the k_mem_pool
+ * API is implemented on top of a k_heap, which is a more general
+ * purpose allocator which does not make the same promises about
+ * splitting or alignment detailed above.  Blocks will be aligned only
+ * to the 8 byte chunk stride of the underlying heap and may point
+ * anywhere within the heap; they are not split into four as
+ * described.
+ *
  * @code extern struct k_mem_pool <name>; @endcode
  *
  * @param name Name of the memory pool.

include/kernel_includes.h

@@ -27,7 +27,11 @@
 #include <sys/util.h>
 #include <sys/mempool_base.h>
 #include <kernel_structs.h>
+#ifdef CONFIG_MEM_POOL_HEAP_BACKEND
+#include <mempool_heap.h>
+#else
 #include <mempool_sys.h>
+#endif
 #include <kernel_version.h>
 #include <random/rand32.h>
 #include <syscall.h>

include/mempool_heap.h

@@ -0,0 +1,55 @@
+/*
+ * Copyright (c) 2020 Intel Corporation
+ *
+ * SPDX-License-Identifier: Apache-2.0
+ */
+#ifndef ZEPHYR_INCLUDE_MEMPOOL_HEAP_H_
+
+/* Compatibility implementation of a k_mem_pool backend in terms of a
+ * k_heap
+ */
+
+/* The "ID" of a k_heap-based mempool is just the tuple of the data
+ * block pointer and the heap that allocated it
+ */
+struct k_mem_block_id {
+	void *data;
+	struct k_heap *heap;
+};
+
+/* Note the data pointer gets unioned with the same value stored in
+ * the ID field to save space.
+ */
+struct k_mem_block {
+	union {
+		void *data;
+		struct k_mem_block_id id;
+	};
+};
+
+struct k_mem_pool {
+	struct k_heap *heap;
+};
+
+/* Sizing is a heuristic, as k_mem_pool made promises about layout
+ * that k_heap does not.  We make space for the number of maximum
+ * objects defined, and include extra so there's enough metadata space
+ * available for the maximum number of minimum-sized objects to be
+ * stored: 8 bytes for each desired chunk header, and a 24 word block
+ * to reserve room for a "typical" set of bucket list heads (this size
+ * was picked more to conform with existing test expectations than any
+ * rigorous theory -- we have tests that rely on being able to
+ * allocate the blocks promised and ones that make assumptions about
+ * when memory will run out).
+ */
+#define Z_MEM_POOL_DEFINE(name, minsz, maxsz, nmax, align)		\
+		K_HEAP_DEFINE(poolheap_##name,				\
+			      ((maxsz) * (nmax))			\
+			      + 8 * ((maxsz) * (nmax) / (minsz))	\
+			      + 24 * sizeof(void *));			\
+		struct k_mem_pool name = {				\
+			.heap = &poolheap_##name			\
+		}
+
+
+#endif /* ZEPHYR_INCLUDE_MEMPOOL_HEAP_H_ */