-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathTODO
89 lines (79 loc) · 4.59 KB
/
TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
+ 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()?)
+ Get core count? It's technically speaking available from the fdt but could be
limited by the NR_CPUS macro, so it might be a good idea to export as a CONF_*
+ The node subsystem might benefit from larger-than-base-page sizes, for example
the RISC-V V extension allows up to 262 144 bytes of register space (though it
seems unlikely that anyone actually uses that many but still)
+ The tests can probably be made a bit more generic, for example we always want
to check for any BUG messages and fail if they are found. Also, most tests
just check if the last message is OK, and we only really need more complex
checking if we need to calculate like memory leaks etc.
+ grow_rpc() shouldn't exceed limits
+ handle_pagefault() should kill processes that have no good reason to pagefault
!!! 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!