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

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