Differences From
Artifact [8818444ab8]:
1 1 #include <k/mem.h>
2 2 #include <k/core.h>
3 3 #include <k/def.h>
4 4 #include <k/type.h>
5 -#include <posix.h>
6 5 /* heapa.c - kmheapa() "heap alloc"
7 6 * ~ lexi hale <lexi@hale.su>
8 7 * kmheapa() allocates a pointer on the heap à la libc malloc()
9 8 * see also: kmheapf() "heap free"
10 9 */
11 10
12 -/* we define all platform functions here,
13 - * whether or not they're for the correct
14 - * platform - only the ones actually called
15 - * by the generated code will be linked,
16 - * linker errors are our friend here! */
11 +/* arch specific headers */
12 +#ifdef KFenv_posix
13 +# include <posix/posix.h>
14 +#endif
15 +
16 +/* we define all our platform functions here, whether or not
17 + * they're for the correct platform - only the ones that are
18 + * called by the preprocessed form of the code will actually
19 + * be linked, linker errors are our friend here! */
17 20 extern void* kmem_platform_mmap(void* addr,
18 21 unsigned long sz, unsigned long prot, unsigned long flags,
19 22 unsigned long fd, unsigned long off);
20 23
21 24 void* kmheapa(sz len) {
22 25 /* allocate an object on the heap and return
23 26 * a pointer, or NULL if the allocation failed. */
24 27 union {
25 28 void* raw;
26 29 ubyte* byte;
27 30 kmbox* header;
28 31 } region;
29 - /* we need to allocate space for the header and
30 - * for the actual object */
32 + /* we need to allocate space for the
33 + * header and for the actual object */
31 34 sz region_size = sizeof(kmbox) + len;
32 35
33 36 # ifdef KFenv_posix
34 - /* posix APIs - we've got it easy. currently for nonlinear
35 - * heap allocation kmheapa simply uses m(un)map and lets the
36 - * kernel worry about it. it may ultimately be worth replacing
37 - * this with a more sophisticated implementation, most likely
38 - * an existing allocator like jemalloc, though i'm wary of
39 - * including outside code - it creates a licensing mess and
40 - * i'd prefer libk to be AGPLv3 across the board. possibility:
41 - * include hooks for multiple allocators, allowing the user
42 - * to select & link in her preferred allocator at compile time? */
37 + /* posix APIs - we've got it easy. currently for
38 + * nonlinear heap allocation kmheapa simply uses
39 + * m(un)map and lets the kernel worry about it. it
40 + * may ultimately be worth replacing this with a
41 + * more sophisticated implementation, most likely an
42 + * existing allocator like jemalloc, though i'm wary
43 + * of including outside code - it creates a licensing
44 + * mess and i'd prefer libk to be AGPLv3 across the
45 + * board. possibility: include hooks for multiple
46 + * allocators, allowing the user to select & link in
47 + * her preferred allocator at compile time? */
43 48
44 49 /* because munmap needs to be informed of the size of
45 - * the region it is going to unmap, we need to store
46 - * that information in the allocated region itself.
47 - * the user will be given a pointer that can be
48 - * adjusted to point a field of type size_t that
49 - * contains the size of the allocate space.*/
50 + * the region we are going to unmap, we need to store
51 + * that information in the region that we are mapping.
52 + * the user will receive an adjusted pointer that can
53 + * be adjusted to point a field of type size_t that
54 + * contains the size of the allocated space.*/
50 55
51 56 region.byte = kmem_platform_mmap(null, region_size,
52 57 posix_prot_read | posix_prot_write,
53 58 posix_flag_anonymous | posix_map_shared, -1, 0);
54 59 /* impl note: while per manpage fd is "ignored"
55 60 * for MAP_ANONYMOUS, "some implementations" require
56 61 * a value of -1 */