Signals are hard. Might do some refactoring instead, particularly with respect to files
Top-level
Signals are hard. Might do some refactoring instead, particularly with respect to files 246 comments
So today is refactoring, particularly for scheduling and file management. @drewdevault great to see you having fun hacking. Will enjoy watching the process. Nice, that's the bulk of the scheduler refactoring done. No pretty screenshot since there are no user-visible changes, but the short of it is that we can context switch to and from the kernel rather than only to and from userspace. (no, I have not set up kernel preemption yet, there are no locks in the kernel and interrupts are always disabled when the kernel is running; as a consequence of that I can only cooperatively context switch the kernel right now) @drewdevault the joy of the first working context switch <3 congrats! Elaborating a bit: the scheduler can now switch tasks while in the kernel and return to the kernel when the thread wakes up, and accordingly waitqueues have been implemented for this purpose. The problem with console devices is that their file descriptors are fake, namely they do not store an inode reference. This is problematic for a few reasons, such as (1) Bunnix lacks a device file abstraction generally; (2) files without an inode blocks adding fstat; (3) we can't mount them in /dev. @dimpase nee, Bunnix is pas 11 dagen oud! Het heeft geen network, geen shell, geen compiler, etc. Day 12 of making a Unix clone New syscalls: getdents, fexecve Fleshed out the filesystem implementation via os:: in the Bunnix port of the Hare stdlib Some more inode refactoring done (f)execve(2) now populates auxilary vector of new process Next: stat/fstat/fstatat, respect/enforce open flags and file modes (e.g. O_WRONLY on a file with -w should not work, implement O_DIRECTORY, etc) Getting lwext4 to actually write changes to the disk is turning out to be a bit involved Spent most of the day failing to get O_CREAT to work on ext4, further investigation tomorrow Answer: turns out it was a bug in the AHCI driver. Took me ages to figure that out. I need to implement an idle task so that the kernel doesn't crash when all processes are blocked, but I don't want to touch the scheduler again ✓ idle Hopefully I don't have to touch the scheduler again until SMP Next up... block special devices. I really need to do signal but blockdevs will let me procrastinate on that Could do sleep(2) as well The scheduler is the biggest time sink so far. The ext4 bug, by comparison, was annoying in that it took a long time to figure out, but in the end the fix was simple. Whereas each time I have to work on the scheduler I have to redesign major portions of it and do heaps of rather difficult debugging of non-linear code. @drewdevault I guess a scheduler is, by definition, lots of nonlinear code? Its been fun watching your experiment from the sidelines. 🙂👍 To implement nanosleep I just improved the wait queues a bit until nanosleep could be done in 33 lines of code Will probably have to change a bit once I implement signals and have to deal with EINTR I think that's everything for day 13: * O_CREAT support for openat Next, in no particular order: * Flesh out files a bit more (e.g. enforce O_RDONLY) Once I get all of those done, it's time to write a blog post about it and resume other projects! Ended up with some extra free time tonight and did a couple more syscalls: unlinkat, mkdirat Remaining filesystem-related syscalls are the stat family of calls, rmdirat (or AT_REMOVEDIR I guess), chmod/chown/chgrp, readlinkat, linkat, symlinkat, and utimensat. Implemented a bunch of openat flags this morning: RDONLY/WRONLY/RDWR is now enforced, and O_DIRECTORY, O_APPEND, O_TRUNC, and O_EXCL are now supported I chose to diverge from POSIX on O_DIRECTORY because I think it's kind of lame, but I could change my mind if this comes back to bite me when I start porting real-world software The cache currently serves just to make sure that there is a 1:1 correspondence between inode numbers and inode data structures (so that if several files hold a reference to the same inode they all remain in sync), it does not persist inodes after all references are released... yet. A broader cache system that keeps cached data in unused RAM is planned for the future. @drewdevault Signals are okay, as long as you offer epoll with signal_fd to tame them! @drewdevault O_DIRECTORY even caused lots of discussion in the Filesystem working group of the POSIX standards committee. @drewdevault Thank you! FWIW, I did go look at https://sr.ht/~sircmpwn, but didn't see bunnix in the projects (quite possible that I missed it) or recent commits to it (just os/+bunnix commits to hare). @drewdevault why did you choose to implement openat and friends? I was planning to avoid them entirely for my toy system. @f4grx they're a better design, using O_DIRECTORY etc, imho. Particularly when it comes to implementing mountpoints. Simplifies things if you don't start from the assumption that you're always walking from the root @drewdevault ah, yes, mountpoints are a tree by themselves, at least in linux. I was trying hard to avoid that in my simplified and NuttX inspired design. I have to check if I can implement the simple traditional syscalls over the _at versions to avoid doing both, my target was embedded with limited storage. |
@drewdevault How do you intend on dealing with signals during a blocking syscall? EINTR? Automatic resuming?