10 10 7. whether writing code or making suggestions, always keep one basic rule of thumb firmly in mind: in all things, [it should be better than libc](http://man7.org/linux/man-pages/man3/strfry.3.html).
11 11
12 12
13 13 ## [kmem]
14 14 ### allocator
15 15 - the `kmheap*()` family of functions currently have a very naive linux implementation, simply [`mmap()`]'ing in and out space that the user requests. it may be worth improving this with a speculative allocation algorithm, that allocates in multiples of a fixed chunk (perhaps tunable in some way by the user? needs discussion) and only call [`mmap()`] when this chunk is exhausted. this introduces fragmentation problems, but may increase speed. rigorous benchmarking would be needed to determine if such a function was worthwhile tho; it may be overall better to go the route described in the [kmheapa] comments and use mmap unless the user compiling libk specifically chooses a local alternative (in which case we would need to write hooks into public malloc algorithms like jemalloc). either way, we need someone who knows more about memory management than me. _~lexi_
16 16
17 - [kmem]: /doc/tip/kmem/kmem.md
18 - [kmheapa]: /doc/tip/kmem/heapa.fn.c
17 + [kmem]: /doc/tip/mod/kmem/kmem.md
18 + [kmheapa]: /doc/tip/mod/kmem/heapa.fn.c
19 19 [`mmap()`]: http://man7.org/linux/man-pages/man2/mmap.2.html
20 20
21 21 ## website
22 22 - i've hacked together a decent theme for libk's fossil repo, but it's a modification of a theme with *really* terrible code. in the long term, we should really design our own. this is good enough for the moment tho. _~lexi_
23 23
24 24 ## project
25 25 - at some point, we need to draft a style guide as well as some general project policies. if libk is to accomplish anything, it needs a much broader base of attention, and if the project scales beyond a handful of people in an IRC room, we can't be taken off guard and derailed. not a priority, but we should start throwing ideas around. _~lexi_