+ 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.
