libk  Update of "roadmap"


Artifact ID: 663927a668e428b94a43d22dfaebcf637be5631ffc4a5474ae9614f0e7c54228
Page Name:roadmap
Date: 2019-08-22 04:07:27
Original User: lexi
Parent: f2a2ceff7e201918ded7911ab5d71b110ed00eb9791b7788ae59f0e4470676a6 (diff)
Next 14aa88c6f8764d65c3f4ab3f1f3bd5c5c76db4011098f31ba273c1dbe800f33f


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.



  • 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


  • 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


  • 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