-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathtodo.txt
100 lines (74 loc) · 6.96 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
Operating System:
* turn on all warnings and clean them up
* something is causing the SLIP serial port to mess up somehow which requires restarting the PC side the setup
* make the tty68681 driver partially write data... right now it'll suspend if the full request can't be buffered, but it should return the partial number, and the read/write syscalls should do
the actual blocking, and then for writing it can rewrite the syscall during the suspend, so that it'll restart in the proper position. You then need to add resuming to tty
* when there's a trailing / to rm or mkdir, it will create something weird
* add timers and retransmissions to tcp
* try transfering files over tcp, to test the stability of TCP (it should be possible to `nc -l 3904 > tar -x` or something to transfer data)
* make checksum command for file integrity
* add a read only mounting mode, such that you know you wont need to sync while also not messing up the CF card
* should there be something that periodically syncs data to disk?
* need a function to convert a device number into a device name or device file path. (Could add another driver function pointer for getting the name of a devnum) (add to /proc/mounts)
* I don't really like the point-of-no-return code in execve(). Is there a way to ensure that wont happen, such as not overwriting the memory segments until the new process is loaded
* make use of 68k's supervisor and user mode. This requires major changes to the create_context since the entry point can't be put onto the user stack. RTE will pop the ret off the supervisor stack
* add calculating of cpu runtime
* add check to vfs_link() for loops
* do you need to disable triggering of the device-indepedent tty bottom half when the serial device is opened directly?
* should there be a vnode op to fill in the statbuf struct, or should they be in the vnode? The only 2 values not in the vnode are blksize, blocks
* the directory size value in the inode isn't working the best. There is no dir size shrinking yet either
* split the boot loader up into multiple parts, so it can be stage loaded
* how can you make a df command to list how many blocks are free?? That info would need to come from the minix fs-specific code
* need to set the ctty in the init process somehow (other systems set it as a special case when opening a tty)
* signals like SIGTTOU are supposed to be sent sometimes instead of returning success or failure
* do you need to implement some internal network routing?
* should you rename vfs_clone_vnode/vfs_release_vnode to instead be vfs_clone_vnode_ref/vfs_drop_vnode_ref ?? The latter would make more sense, albeit be longer
* move interrupts.c/h to its own arch dir somewhere. It contains the last m68k specific assembly, but requires a subdir in src/kernel for the code, along with the syscall_entry.s and start.s files
* you could possibly make an abstracted packet construction thing using an ioctl-like function defined for each protocol, which can intercept parts of
the requests to fill in data in the packet headers (set src address, set dest address, add id, etc)
* implement dns
* add pipe setup to command evaluation
* add the & (run in background) option to the shell
* add support for * in shell
* make a simple web server
* add fifos (should be easy now)
* implement unix domain sockets
* add stack guard protection
* implement login system (setuid)
* implement fcntl
* implement symlinks in minixfs
* optionally implement ftell, fgetpos, fsetpos
* can you implement some kind of terminal switching, like alt-F* keys... It would have to be more like `screen`
* make a /dev/flash0 device or /dev/rom0 device in the mem.c driver, possibly even with a partition table and bootloader, that can be mounted read only
* port some kind of interpreter, like scheme
* try porting a simple command, and then something more complex, maybe awk or something as a big target
* implement fg/bg somehow... it would be builtin to the shell and would require job control stuff...
* add commands: rmdir, dd, chown, grep
* implement shell scripting?
* add up/down arrow processing to the shell (easy without cooked input, but how would it be done with...)
* add some kind of debugging or tracing support
* make a PIE format that can be loaded and executed (this will likely require a custom linker script)
* should there be a lighter weight task type, instead of processes, so that you can service interrupt processing without a bunch of wasted memory
* should you add timestamps to packets? (not currently a use for it)
* rewrite the math functions to use fewer registers, and cover the 32 bit divide by 32 bit number case
* minixfs, implement versions 2 and 3
* implement links for mallocfs
* should you refactor the header files in minixfs implementation into actual c files, with a common header to declare the functions?
* do you need to add variable sized buffers/blocks into bufcache? (yes)
* can you change the fd allocator, such that calling it twice will return 2 different fds, even though they aren't reserved until set
(ie. store the last allocated fd, but it has to be in the process struct)
* remove the execbuiltin syscall, which is temporary until all commands can be executable files
* there is an issue running the shell on linux related to the setting the process group
* could you use the queue node to add procs to a free list, instead of iterating over all the procs when creating a new one
* the return from syscalls is sometimes generating a move %d0, %d1; move %d1, %d0
* re-evaluate file permissions checks to make sure they're correct according to posix
* you need some tests, but ideally it would use a simple emulator. Maybe easy68k or something could be used
* It *might* be possible to defer the context save until you're certain a reschedule is needed just before exiting, but it would require being very careful during the stack swap
* as a note about terminology for pseudoterminals, pts/ptm (slave/master); it would make more sense for them to be named process-end and device-end, which implies
the expected interface to each. A user process will open the process-end terminal device and communicate with it like any tty. The emulator or whatever would
connect to the other end and act as if it were a terminal device, in place of what would be an actual I/O device like RS-232 or a hardwired keyboard. I guess the
abbreviations might be /dev/ptpX and /dev/ptdX?
Monitor:
* failure vectors don't point to the correct addresses, from the looks of it
* can you have an debugger in the monitor software? There are trap and breakpoint instructions in the processor for debugging, so if you define an interrupt handler
for those, you could have it enter a debugger, that possibly allows single stepping? I'm not sure how to implement that