Email or username:

Password:

Forgot your password?
Top-level
Drew DeVault

Call it 32 lines, that assert belongs somewhere else

217 comments
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 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

Drew DeVault replied to Drew

EFI w/framebuffer console via GOP

Drew DeVault replied to Drew

Left: old thinkpad w/legacy boot
Right: modern starlabs starbook MkIV w/EFI boot

Both booted from the same flash drive :)

Drew DeVault replied to Drew

EFI support ended up consuming all of day 15. D&D tonight!

Drew DeVault replied to Drew

Day 16: I am porting musl libc to Bunnix

Drew DeVault replied to Drew

Wiring up more of stdio.h

Drew DeVault replied to Drew

End of day 16:

* New syscall: fstatat (currently AT_EMPTY_PATH only, i.e. fstat(2) behavior)
* Serious build system improvements, to add...
* A sysroot during the build, into which...
* An early port of musl libc has been installed, including varying degrees of support for stdio, math, complex, ctype, malloc, string, unistd, stat, and more

Unfortunately I'm now fully committed to GNU make, but this build is too complex to really get away with POSIX makefiles.

End of day 16:

* New syscall: fstatat (currently AT_EMPTY_PATH only, i.e. fstat(2) behavior)
* Serious build system improvements, to add...
* A sysroot during the build, into which...
* An early port of musl libc has been installed, including varying degrees of support for stdio, math, complex, ctype, malloc, string, unistd, stat, and more

Drew DeVault replied to Drew

Goal for the end of the week is to have a pretty decent C environment with a shell and a decent spread of coreutils ported, probably a bourne shell derivative plus sbase.

I'll port DOOM, too, if all of that is done before Saturday.

Drew DeVault replied to Drew

Fleshed out libc a tiny bit more and tried to port some sbase utilities before calling it quits for today

Drew DeVault replied to Drew

Another day, another GCC cross compiler

Drew DeVault replied to Drew

So, in the morning of day 17, I have three languages running in userspace: Hare, C, and C++

I will keep fleshing out libc and the necessary syscalls until we have a shell. I suspect there is another scheduler bug as well.

Coming up soon: pipe(2), dup(2), fcntl(2)

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