diff options
Diffstat (limited to 'TODO.txt')
| -rw-r--r-- | TODO.txt | 77 |
1 files changed, 0 insertions, 77 deletions
diff --git a/TODO.txt b/TODO.txt deleted file mode 100644 index f0265f5..0000000 --- a/TODO.txt +++ /dev/null @@ -1,77 +0,0 @@ -+ 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! |