D 2019-08-24T00:12:40.176
L roadmap
N text/x-markdown
P 663927a668e428b94a43d22dfaebcf637be5631ffc4a5474ae9614f0e7c54228
U lexi
W 3288
# roadmap
this page should be used to add suggestions, thoughts, and ideas for further directions libk should/could take, including suggestions for new modules. please keep the following in mind when editing:
1. if you need to link to source code and do not need or want a specific version, prepend its path with the string `/doc/tip` - this will generate a link to the current version of the document.
2. please keep things tidy and use ATX-style links for files and short labels at least — put [brackets] around the link text, then at the end of the section, indent by two spaces and write e.g. `[brackets]: /doc/tip/global/bracket-frobnicate.awk` next to the nearest link, or in a paragraph by itself if there are no other links.
3. try to keep material in the section for the module it pertains to, if any. this is not a wikipedia discussion page: if you wish to comment on another team member's suggestion or suggest a roadmap change/addition/deletion, please do so in IRC or the forum.
4. reference functions by their full name, not their filename.
5. as a courtesy to prospective users and developers who may not be familiar with the innards of the linux kernel, please link references to system calls and functions to their relevant documentation.
6. please sign your name if you add something without consulting/working the rest of the team on it, and mark up the text so it stands out from the text of the paragraph.
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).
## [kmem]
### allocator
- 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_
[kmem]: /doc/tip/mod/kmem/kmem.md
[kmheapa]: /doc/tip/mod/kmem/heapa.fn.c
[`mmap()`]: http://man7.org/linux/man-pages/man2/mmap.2.html
## website
- 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_
## project
- 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_
Z 04c8357453a1e566e7965517c75662d4