229 comments
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. Okay, about done for today. Summary of day 14 writing a Unix clone: New syscalls: exit, waitpid Improvements to openat: enforces read/write mode, supports O_DIRECTORY, O_APPEND, O_TRUNC, O_EXCL, and O_CLOEXEC Added an inode cache Optimized the MMU code for fork and process clean-up (still no CoW, though) And laid some groundwork for signals, which I have been dreading from the start. initramfs :D Simon Zeni ported the Helios EFI bootloader to the Bunnix boot protocol last night, so I'm doing some other boot improvements this morning to get EFI support upstreamed Left: old thinkpad w/legacy boot Both booted from the same flash drive :) @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. @mxk I haven't implemented fsync and presently all writes are committed to disk before write(2) et al returns to userspace, so I'm not sure. I might know more when I get to that. @drewdevault @bugaevc okay, yeah, that is reasonable. @drewdevault @mxk guess it can be useful — for atomicity, or for reducing the number of file name lookups in find(1)/ftw(3) if readdir returns DT_UNKNOWN — to be able to open() a node first, then fstat it, and if it's a directory do one thing (look up something relative to it with *at()), and do another thing otherwise. @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. |
Answer: turns out it was a bug in the AHCI driver. Took me ages to figure that out.