diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 77 |
1 files changed, 77 insertions, 0 deletions
@@ -0,0 +1,77 @@ ++ Investigate GCC/Clang builtin atomic operations? + ++ Implement more type operators in dbg, mainly intmax/uintmax and size_t + ++ Add in mapping the same memory to two different processes (sort of?) ++ Create sensible thread handling ++ Add in init process loading ++ Make sure vmap is in 4K increments or whatever (fuck it, sure) ++ Remove/converge convnum and debugging __atoi ++ Create actual init program (meh, sort of) + ++ Add in (attempting) to map into specific region of memory, see phone for +details dumbass ++ Primarily memory should be allocated to a process through mmap-like +functionality, but brk/sbrk can probably still be emulated. If s/brk maps memory +that's later attempted to mmap, it fails, and vice versa. Apparently should be +acceptable by Unix standards. (or just make brk in libc a noop?) ++ Alignment can maybe still be used, though more in the sense of using larger +pages? YES, CHECK common/vmem.c:map_fill_region! Should be implemented there as +well ++ check elf.c "skip while testing" comment, remove when sufficiently pleased +with the system. Christ, what a terrible way to develop software :D ++ Start working on syscalls etc. + ++ NUMA is probably fairly easy to setup, just add more pmaps I guess, although +it does sort of mess with the current device memory setup, which assumes there +is only one memory region and everything below/above it is device memory +regions. Not entirely sure how to handle that situation, i.e. is it safe to +assume all devices are below the first NUMA node? No clue. + ++ The dev interface can be abused, if a program decides to spam through all +memory addresses the system will probably run out of memory. Not sure if it's +worh doing anything to. + ++ TLS. Can this be done completely in userspace? + +!!! CURRENT: + ++ Separate vmem and devmem to have a common 'backend', like mem_nodes or +whatever, would probably make it a bit more clean-feeling. (x) ++ Add in interrupt handling and start testing jumping back and forth. ++ Add in better tcb handling, mainly creating linked lists with all threads +under a common process ID. (sort of done, not sure if linked lists even + necessary) ++ Start implementing IRQ handling ++ Timers should use the sp_tree thing sorted by time of completion, and then +each timer interrupt just pops the smallest value off and jumps to the +associated program. Easy. (started) ++ Add more flags to memory regions, for example MR_SHARED and MR_OWNED? done ++ DOCUMENTATION ++ Start working on proper context swaps and RPC swaps. (which thread ID should + be visible from cur_tcb() when in an RPC? should I use some kind + of effective tid instead of cur_tcb()?) + +!!! FUTURE: ++ Cache locality? ++ When mapping some other address space into your own, I could keep a maximum +used address of the guest address space and only map so many pages, which could +be better for cache locality. ++ Assert? Not sure how to handle a kernel panic at the moment, I guess just die? ++ Add in more logging etc. dumbass ++ More functions, less macros? sometimes helpful in gdb, maybe also for kernel +binary size? ++ Add in purely virtual memory pages, i.e. stuff that shouldn't free physical +memory when the memory page is freed, for example if two processes share the +same memory (started on it) ++ Arches will need to implement timers. All in all, in kernel there should be +SMP, IPC, timers a memory manager, everything else in userspace. ++ Choose between allowing the process manager to interrupt other cpus and each +cpu starts its own process manager with a timer of some sort? ++ More const correctness, possibly better assembly but don't count on it. ++ Create some gdb scripts to ease debugging, sort of annoying to have to +constantly switch between physical and virtual ram ++ Save floating point registers? ++ Come up with a list of requirements for arch to be supported, from what I can +tell there has to be timers and at least two tiered memory paging. ++ TLS! |