OSDev.org

Finally got a framework for pseudofilesystems working, started work on an implementation of procfs using it. Upto this point, there was no way for a process running on my kernel to know about other processes (except for maybe something like kill()'s status return or waitpid())

Looks really good. But the link in your signature isn't working.

Greetings
Peter

Nothing terribly exciting out of this neck of the woods. Runtime configuration is coming together, as can be seen here:



Meanwhile I'm also working on laying out some documentation once again for compilation into a book to go along with the system:


Click for big.

Hmm. I need to fix that, https://github.com/posnk/posnk/ is the kernel.

Also, getting pretty close to being able to implement an userland debugger in my OS

Do you have any pre-built release downloads?

Not any good ones, at the moment, unfortunately. Things are still somewhat broken after some major kernel refactoring. (i started the project back in '14 when i was still in high school, needless to say, i've learnt a lot since then.)

My testing at the moment uses a pretty barebones rootfs, and I also haven't yet added a lot of the new features to my busybox port.

I'll throw together a quick image without a gui or VIM. Don't have a bootloader setup script handy so you'll have to use "-kernel" on qemu.

To run using ATA harddrive (RW root):


To run using ramdisk (slow boot, but can be used on real HW too):



Kernel: https://pbx.sh/upl/vmpos (<2M)
Root FS: https://pbx.sh/upl/demoroot.img (128M)

This is still a pretty damn unstable build, and one of the things on top of the To Do list is to add a UBSAN runtime and clear out some of the code rot.
I had signals working fully before I added multithreading to the kernel, they are somewhat buggy now.

If you want to debug some program, set the sercon level to trace, and you'll get a strace-like output from the serial console

@Kazinsal: What's the .\\pipe\compipe in Putty's title? If that's a way for Putty to connect to a VM's serial port, I'm super-interested!

I might go for asymmetric multiprocessing myself.

\\.\pipe\ is the NT namespace for named pipes, and PuTTY can open named pipes as serial ports like so:


On the VirtualBox side, it's configured like this:


Make sure to uncheck "Connect to existing pipe/socket" so VirtualBox creates the named pipe when the VM starts and closes it when it stops. It'll keep it open if the OS restarts the VM or if you "hard reset" it, so you won't lose any scrollback on a restart. I use it when testing changes, as I can build a new ISO, tab back over to PuTTY, type "reload" into my console, and then once it finishes rebooting I can run my test and scroll up to compare output.

@Kazinsal: Thanks! I was hoping NT had something like this.

@astralorchid: Is that 3 programs? (terminal, test, and shell?) Whether it is or it isn't, it looks like you're getting somewhere.

the terminal is the shell and loads like a program, but it's a bit more connected to the kernel.

I also took Terry's advice and looked into INT 0x13/AH 0x42. Now the OS is booting on everything from an old 32bit BIOS to a UEFI with CSM from this year.

That's fair enough. I'm not keen on normal terminals anyway.


Cool.

New progress:
- Debugger is now accessible from very early on during booting, using text mode
- Many debugger improvements
- Drivers are now dynamically loaded instead of being compiled into the kernel. Drivers for boot media are loaded using function provided by boot sector.
- Doesn't crash as much
- Can run more DOS programs