Initial version of "roadmap"
1 +# roadmap 2 +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: 3 + 4 +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. 5 +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. 6 +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. 7 +4. reference functions by their full name, not their filename. 8 +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. 9 +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. 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 + 12 + 13 +## [kmem] 14 +### allocator 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 + 17 + [kmem]: /doc/tip/kmem/kmem.md 18 + [kmheapa]: /doc/tip/kmem/heapa.fn.c 19 + [`mmap()`]: http://man7.org/linux/man-pages/man2/mmap.2.html 20 + 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_ 25 + 26 +## project 27 +- 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_