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 17 [kmem]: /doc/tip/kmem/kmem.md
18 18 [kmheapa]: /doc/tip/kmem/heapa.fn.c
19 19 [`mmap()`]: http://man7.org/linux/man-pages/man2/mmap.2.html
20 20
21 21 ## website
22 -- libk needs its own fossil theme. i need to find the energy to do this. contributions are welcome, and haranguing me into doing the damn job count as a contribution. _~lexi_
23 - 1. step one: justify the goddamn body text. my eyes itch reading this. _~lexi_
24 - 2. heading levels. need to be adjusted to be more distinct. _~lexi_
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_
25 23
26 24 ## project
27 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_