-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathtodo.txt
145 lines (96 loc) · 9.01 KB
/
todo.txt
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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
* for multi-core support, you first need per-cpu memory allocation (and maybe go into rust before kernel_start)
* make a USB driver (so you can access the ethernet module)
* should you change the memory map functions to take an end address instead of a length?
* add stack page guard, which would have to be created when the loader creates the stack, and also when sbrk/adjust is called
* write tests for mmu translation tables
* there could be a memory leak with pages. When the shell exits, you can print all the allocated pages that aren't freed
* is there a way to get automatic ref counting for pages? The actual page is being stored in as a PhysicalAddress in the
page table, but what if you always took/gave a refcounted value, and have the translation table destroy the ref without
decrementing the count, and then create a new uncounted ref from the physical address, once only.
The issue here is that you need a way, from the page descriptor alone (although you have a fixed address for it) to determine the
page, and thus PhysicalAddress, so that you can switch back and forth (between an Arc<Page> and a PhysicalAddress)
* switch/fix the console driver that tries to use buffered I/O (the interrupt doesn't get triggered in a way that makes it difficult to
completely avoid directly writing to the hardware FIFO)
HIGH PRIORITY ISSUES:
* should you make a new `subsystems/` directory to contain block, tty, usb, maybe fs? (and have it compile flagged))
* If you did this, would arch/, proc/, and mm/ still be in the kernel? Would api/ move to its own thing, or to the subsystems
Should misc be moved to lib/ somewhere?
* can you make things like the open files for a given process be stored outside the task struct in a way that's linked or easily findable?
then those dependencies can be removed from proc/ so that it can stand on its own (kernel code must not reference subsystem/ code, but it
could reference lib/ code)
* need to add a way to remove from pagecached files that are no longer used
* unify bufcache and page cache
* for bufcache, and the issue of block size vs page size, you could maybe make it so that all bufcaches are page sized, but it will give
the filesystem whatever block size it requests by returning a subslice of the actual page (only works for page size >= max block size
* should you make the kernel heap use pages instead, and if so, where in virtual memory would the heap space be located?
* need to eventually convert kmalloc to use the paging system (with a kernel page flag if necessary) (I can't remember what sparked this?)
* can you replace the process vec with a hashmap? The issue is iterating over the list for procfs readdir support
* should you split the api into a linux one and a ruxpin-specific one that is very rusty? If you did, it would make sense to
make the various api's modular and external to the kernel, in their own crates
TODO:
* (verify) modify a user fatal error so that it just terminates the process instead of kernel panic
* implement api getcwd()
* add networking
* add threading support in api
* think about multicore and what that would mean for everything
* add a stack guard page to each stack segment, with permissions/mapping in the translation table such that it will cause a fault
instead of crashing into the adjacent segment. Linux has this adjustable in size I think
* make the elf loader create a data segment if one is not already created as part of the executable (or should we assume the elf will
always create a data segment even if not used at all). So that there's always a data segment to grow when more heap is requested
* add mounts to procfs (and make mount command)
* add an events system for processes to wait on (IO blocking, process exit, select/poll, etc)
* fix the blocking/unblocking code (including exits) to use multiple queues and an event system of some sorts to improve the performance of checks
* add a function to libapp to help parse simple command line arguments
* implement vfs::link()
* make methods on File for fs operations (including unlink/rename?), so you don't have to always use vfs::read(file)
* there's a lot of inconsistency between Ext2BlockNumber and BlockNum in ext2 which should be resolved somehow
* fix the ugly stack manipulation used for the command line arguments. Can you make one set of arguments available to the process and also
to procfs (via the task record)?
* add more data to procfs
* add arrow key support to canonical input
* add commands: cp, pwd, mount, umount
ISSUES:
* should you rename unmap_range, map_paged_range, reset_page_copy_on_write, etc to range_unmap, range_map_paged, page_reset_copy_on_write
* think about threads. I think linux makes every system thread a process with optional sharing of memory and file descriptors, but I
had been thinking of making thredas separate, making them scheduled, and since there could be a current thread and a current process
tracked separately by their respective managers (first thing in queue), then a page fault wouldn't have to look up the context, and
a system call that accessed files would have to fetch both (but not find one via the others)
* need to sort out the tty devices. how irqs can access the device object. whether only the tty subsystem or the driver as well, has
a reference to the devices as well. how the config will create the device object, and where it stores it (or does it assume each
driver will register and save global references to the devices if needed? Is there a better way than using so many global references?
* there's an issue with serial input on the hardware, where it wont show up until a certain number of keys are pressed, but it's a bit
unpredictable. I think it might be an issue with when the interrupt occurs based on the buffer fullness?? Could be totally wrong
* sort out issues of copying to/from user space
* there is no userspace/kernelspace copying in the api, which could cause a fatal error if the user program doesn't give a valid
input, so at some point this needs to be added
* does the linux copy user/kernel function do manual page lookups, including triggering page loading? Or does it do soemthing else?
* there is an issue with the emmc driver such that when the image used with qemu is below 2GB or less, the Read command gives a byte
offset, but when it's 4GB or larger, it gives a sector offset (byte offset / 512). I'm not sure if this happens with the pi as well
since I only have an 8GB card. If there was a way to detect the card size, this could be solved
* should the api be an external crate that integrates the public interfaces (only) of the kernel?
* should you move SyscallFunction type to libapi, since the functions are defined there? Could you use generics for the syscall itself?
How will that work for saving the syscall in the task/process? Could you make a separate place to save that data in the api, on a
per-task basis?
WHAT IFS:
* how could I make it more event-oriented rather than traditional unixy
* what if you added json for procfs's data, to make it easier to parse? What if you made json and/or unixstd file formats a compile
time feature flag? What if procfs (and all the others) where their own crates with their own feature flags, that are tied together
by a toplevel config crate (ie. the breakup into crates)
* how would you isolate the unix-specific aspects of the api such that you could implement a light unix-to-ruxpin
shim on the user process side (or even on the kernel side), so that the ruxpin-native api is not constrained by
unix but is compatible enough to be source compatible. Things like waitpid, which take a pointer to the location to put the status,
it would be nice to have a safer means of passing back data
* can you separate the syscalls, maybe even based on permission levels as well as function, and require permission for each api to
be granted explicitly, so that APIs security-wise are opt-in, kind of like a web api, or like WASI
* I'm leaning a lot more to the idea of splitting up the APIs into different groups with a different svc number for
each. The aarch64 stuff can have the svc-to-api decoding because it might need to be platform specific
LOW PRIORITY TODO:
* modify the proc macro for encoding system calls to be a bit cleaner (not have to put the {} at the end, fit it all in one line, etc)
* there is currently no checking for illegal characters in each path component
* fix rename on ext2 to more intelligently rename (if the parents are the same and the direntry can be reuse, then do that)
* it turns out there's a from_le and from_be function for u32 and others, so maybe you can simplify the byteorder stuff using them
* can you use a weak reference of some kind for the mount link, instead of NonNull?
* add a proper timer driver (ie. fix the hackish ARM timer driver)
* add functions to delay by a set number of microseconds (might need to use the internal counter), for use by drivers
* get the app linker script working better (can you align to 4KB instead of 64KB)
* can you make an improvement on DeviceRegisters, or should you just use tock-registers