conform closer to other project structures

1 files changed, 77 insertions, 0 deletions

diff --git a/TODO b/TODO
new file mode 100644
index 0000000..f0265f5
--- /dev/null
+++ b/TODO
@@ -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!