Email or username:

Password:

Forgot your password?
Top-level
Drew DeVault

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.

235 comments
Dima Pasechnik 🇺🇦 🇳🇱 replied to Drew

@drewdevault interesting OS name... Woont u in Bunnik? 🙂

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

Character special device files baby!

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.

JayT replied to Drew

@drewdevault I guess a scheduler is, by definition, lots of nonlinear code?

Its been fun watching your experiment from the sidelines. 🙂👍

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

Call it 32 lines, that assert belongs somewhere else

Drew DeVault replied to Drew

Block device files are now mounted, not that you can open them

Drew DeVault replied to Drew

Right, now you can open them

Drew DeVault replied to Drew

I think that's everything for day 13:

* O_CREAT support for openat
* Character and block devices, incl /dev/null, zero, full, and block devices and partitions
* Populate /dev with devices on boot
* Add idle task to scheduler
* New syscall: nanosleep

Next, in no particular order:

* Flesh out files a bit more (e.g. enforce O_RDONLY)
* Flesh out filesystem syscalls (mkdir, fstatat, etc)
* Signals & waitpid
* pipe(2), dup(2)
* Start writing a libc
* Port a shell

Drew DeVault replied to Drew

Once I get all of those done, it's time to write a blog post about it and resume other projects!

mort replied to Drew

@drewdevault Blog post material driven development

Drew DeVault replied to 💻 okflo 🤸

@okflo oh god now I have to port doom to it

Drew DeVault replied to Drew

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.

Drew DeVault replied to Drew

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

Drew DeVault replied to Drew

Also implemented an inode cache and reference counting for inodes 😃

Drew DeVault replied to Drew

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.

Drew DeVault replied to Drew

many process, much wait

Drew DeVault replied to Drew

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.

git.sr.ht/~sircmpwn/bunnix

Drew DeVault replied to Drew

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

mxk replied to Drew

@drewdevault Signals are okay, as long as you offer epoll with signal_fd to tame them!

mxk replied to Drew

@drewdevault O_DIRECTORY even caused lots of discussion in the Filesystem working group of the POSIX standards committee.
Are file descriptiors obtained with O_DIRECTORY useful for sync_fd() in your implementation?

Drew DeVault replied to mxk

@mxk what is sync_fd()? Do you mean fsync?

mxk replied to Drew
Drew DeVault replied to mxk

@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.

mxk replied to Drew

@drewdevault then I am doubly curious, what did you change about O_DIRECTORY?

Drew DeVault replied to mxk

@mxk @bugaevc I made it so that you can *only* open directories with O_DIRECTORY and they can only be O_RDONLY

mxk replied to Drew

@drewdevault @bugaevc okay, yeah, that is reasonable.
I ask, since I can't count the times I had to explain to someone, that O_RDONLY and O_DIRECTORY both are ways to create file descriptors to a directory, but both are fundamentally different in nature.
(And given that nobody checks return values of fsync() this mistake is unlikely to ever be discovered)
Also, reading from directory fds is a mess and shouldn't be supported by any posix system....

gtk4-bugaevc.EXE replied to Drew

@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.

Drew DeVault replied to gtk4-bugaevc.EXE

@bugaevc @mxk I guess that makes sense. We'll see what people are doing in the wild when I start porting software and it trips over this

Jason Bowen replied to Drew

@drewdevault Will the source be made available for folks to gawk at?

Jason Bowen replied to Drew

@drewdevault Thank you!

FWIW, I did go look at 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).

F4GRX Sébastien replied to Drew

@drewdevault why did you choose to implement openat and friends? I was planning to avoid them entirely for my toy system.

Drew DeVault replied to F4GRX

@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

F4GRX Sébastien replied to Drew

@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.

Go Up