Day 8 was all about getting userspace online. We are loading ELF programs, jumping into userspace, and we have working interrupts and syscalls
Day 9 will start implementing more useful syscalls and fleshing out I/O
Top-level
Drew DeVault
Day 8 was all about getting userspace online. We are loading ELF programs, jumping into userspace, and we have working interrupts and syscalls Day 9 will start implementing more useful syscalls and fleshing out I/O 215 comments
Josef 'Jeff' Sipek replied to Drew
@drewdevault I'm really impressed how quickly you're implementing this.
Drew DeVault replied to Drew
I confess that I rushed into userspace without a plan, so I have a bit of a mess to figure out once I decide how to actually structure the project properly. But that aside, I implemented a handful of syscalls today, notably readv, write, and mmap (MAP_ANON only, for allocations)
_L4NyrlfL1I0 replied to Drew
@drewdevault You're basically at the point where my university's OS exercise starts out. We're given a (IMO pretty horrible) codebase with a basic OS that has a scheduler, page allocator, basic filesystem and block device layer, basic userspace with a few I/O calls, a very non-posix CreateProcess syscall, and a minimal shell to start testcases with. 1/2
Drew DeVault replied to Drew
Okay, reorganized the source tree to make a lot more sense before we move any further into userspace. Took some inspiration from the BSD layouts, since I intend to ship kernel and userspace as one cohesive project.
Drew DeVault replied to Drew
Day 10 is getting fork working (and preemptive multitasking) Getting there.
Carlos O'Donell replied to Drew
@drewdevault Sorry, no judgement here, just wanted to point out an interesting paper I'd read recently only for the first time. And that perhaps might influence how deeply one plumbs fork as an abstraction into the OS.
Jiří Stránský replied to Drew
@drewdevault Are there resources that you use or that you'd recommend to someone wanting to learn about these low-level OS topics? Perhaps some books / websites or something like that?
Drew DeVault replied to Jiří
@jistr osdev wiki and the manuals/specs for the hardware you want to work with
Drew DeVault replied to Drew
Summary of work up to day 10: * AHCI driver
Drew DeVault replied to Drew
Signals are hard. Might do some refactoring instead, particularly with respect to files
mort replied to Drew
@drewdevault How do you intend on dealing with signals during a blocking syscall? EINTR? Automatic resuming?
Drew DeVault replied to Drew
So today is refactoring, particularly for scheduling and file management.
crypt17 replied to Drew
@drewdevault great to see you having fun hacking. Will enjoy watching the process.
Drew DeVault replied to Drew
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.
Drew DeVault replied to Drew
(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)
F4GRX Sébastien replied to Drew
@drewdevault the joy of the first working context switch <3 congrats!
Drew DeVault replied to Drew
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.
Drew DeVault replied to Dima Pasechnik 🇺🇦 🇳🇱
@dimpase nee, Bunnix is pas 11 dagen oud! Het heeft geen network, geen shell, geen compiler, etc.
Drew DeVault replied to Drew
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)
Drew DeVault replied to Drew
Getting lwext4 to actually write changes to the disk is turning out to be a bit involved
Drew DeVault replied to Drew
Spent most of the day failing to get O_CREAT to work on ext4, further investigation tomorrow
Drew DeVault replied to Drew
Answer: turns out it was a bug in the AHCI driver. Took me ages to figure that out.
Drew DeVault replied to Drew
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
Drew DeVault replied to Drew
✓ 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
Drew DeVault replied to Drew
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.
Drew DeVault replied to Drew
To implement nanosleep I just improved the wait queues a bit until nanosleep could be done in 33 lines of code
Drew DeVault replied to Drew
Will probably have to change a bit once I implement signals and have to deal with EINTR
Drew DeVault replied to Drew
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) |
There we go. That's probably all for today.