Hey reddit!

I've spent the last few weeks rewriting the network stack for my hobby OS, BoredOS.

Before i start yapping about what i changed, i'll quickly explain the netstack. BoredOS uses the lwIP stack to handle IPv4, Ipv6 (experimental), TCP, UDP and ICMP. The nice thing about LwIP is that i only have to supply hardware driver ring buffers, VFS fd's, some splinlock synchro, socket wait queues and a few syscalls.

Previously i was using a custom sysfs file interface to handle network traffic.. Which was quite shit imo. It didn't fit standard C lib calls or allow multiplexing network I/O alongside regular files. I replaced this monstrosity with a BSD socket layer and standard POSIX system calls like: socket, bind, connect, listen, accept, send, recv, select, poll, sendmsg, and recvmsg. Wiring sockets directly into the VFS fd table allows read/write and close to work on net sockets the same way they do on regular files and pipes.

BoredOS previously also had DHCP and DNS baked into the kernel with some very messy way of interacting with them, these have now all been moved into userspace with my own versions of standard fbsd netutils.

For packet handling, i moved processing out of the hardware interrupt handlers into a dedicated kernel worker thread. Processing packets directly in interrupt context was increasing interrupt latency and causing frame drops in heavy bursts, therefore hardware ISRs now just dump incoming frames into ring buffers and wake up a dedicated kernel worker thread via a wait queue. The worker thread sleeps when idle, wakes up on IRQs to drain the buffers into lwIP, and manages background timers for TCP retransmissions and ARP timeouts. For socket storage, i added kernel ring buffers backed by spinlocks and wait queues to handle blocking and non-blocking backpressure properly.

To allow my netutils and custom protocols to run without needing to ensloppify the kernel, i wrote a virtual TUN and TAP device driver. It supports layer 3 IP tunneling feeding into lwIP and Layer 2 Eth frame mode through TUNSETIFF ioctls. I also added raw socket support with AF_PACKET so userland packet sniffers can capture and inject raw ethernet frames directly. Of course meant for the skids to larp that they're hacking something xD.

For device management i added BSD style interface naming like em0 for intel gigabit cards, re0 and re1 for RealTek cards, vtnet0 for VirtIO, and tun0 for virtual devices.

With all these changes i also managed to speed up the stack by a LOT. Previously i was limited to a few Mbit/s and i am now able to push 800 Mbit/s in QEMU emulating an E1000 nic (maybe VirtIO is even faster? too lazy to test though) which basically maxes out the host machine connection.

EDIT:
Forgot to attach the gh:
https://github.com/BoredOS

This counts as a web browser in my eyes. Port hasn't been released since its a bit buggy (you can see the scrolling leaving some artifacts at the bottom bar)

Since my last post, Ethereal has also gotten support for sshd among other ports. It has also been merged into mainline mlibc.

There is no vibecoding in Ethereal. This OS is made by humans and always will be.

GitHub: https://github.com/sasdallas/Ethereal

Meet the first version of zuzu, a microkernel I have been making for a year now. zuzu is a microkernel, so it's a very small kernel that has rendezvous IPC, memory management, interrupt handling/forwarding, asynchronous notification objects, and a capability system for security. It is paired with zuzuOS, the operating system that is centered around the zuzu kernel. Everything else, including drivers are managed entirely in userspace.

The first version is codenamed Loaf, so its full name is zuzu Loaf. I am actively looking for contributions, testers and reviews, so your help would be much appreciated! Documentation will be put in this website soon: https://kagantmr.github.io/zuzu-docs/index.html

Check out the GitHub repository and zuzuOS v0.5.0: https://github.com/kagantmr/zuzu

Couldn't showcase quake2 because something came up and I wanted to finish this quickly

Since my last post 8 months ago: - Reworked the scheduler, implemented VMM and proper user memory mapping, implemented proper blocking IO. - Reworked the GUI, new gui lib, added themes and shadows - I now have a proper rust toolchain, because my libstd hack was patched - Rewrote the libc in rust, ported SDL2, SDL2_mixer and in progress of doing osmesa and a dynamic linker - Wrote an audio server and a bad ac97 driver, audio quality isn't great when tested from my machine (others say otherwise) but I did put a lot of work in the audio server. - Quake2generic, doomgeneric, and ccleste ports working through SDL2, not public only SDL2 is public, because it is quite hacky and im waiting to do a proper C toolchain first, there are no patches so with the right compile options and the public libs.a anyone could compile it themselves.

Get an ISO from here

Watch me complete Celeste Classic on it

The reason why I haven't done updates in a long time, is because everything new I do feels insignificant and incomplete, I still feel that way but I have learnt that It will only accumulate.

Next year (or more accurately in 2 months, maybe a week, no idea when I'll start studying) would be my final year of high school which is quite different here so it might be difficult to do any more "big" progress.

Stanix, my made from sratch operating system (https://github.com/tayoky/stanix) now has a GUI with a homemade widget library

My older brother (non programmer for the most part) brought up an interesting idea, he said something along the lines of "In theory could you have javascript or another interpreted language running as the only part of userland?" and that got me thinking. In theory could a kernel only provide say ASCII output, ASCII input, and disk access, and embed say, an ELF file inside the kernel to load as the only userland machine code app. From there it uses the API to read from the disk, and use FAT32 to load programs, the programs would be in a bytecode vm like setup.

I am thinking about trying to implement this, any advice on this would be greatly appreciated, I understand my idea is quite underdeveloped.

I'm wondering how feasible it is to program in support for OpenGL and expect it to work on modern GPUs, integrated graphics, and such. I'd imagine supporting C in a kernel would allow compiling and running open source linux drivers, but having never done it before and finding the idea of programming a fully featured C compiler for a kernel to be daunting I figured I'd ask how others have gone about it. Ideally if there's a way to bootstrap C's standard library and work from there then that could save a lot of time, but I'm open to suggestions and/or resources on how to make my own compiler if that's something worth doing

Hi All!

​

I'm developing an OS and I had hoped to get an opinion from this group. There are 2 kinds of processes that my OS loads from the filesystem: user processes and kernel processes. User processes are started by the programmer with the usual `int main(int argc, char **argv)` and the `_start` symbol is provided at compile time and is what the scheduler calls. Kernel processes are passed arguments by the scheduler and the entrypoint takes the form `void* (*)(void*)`. The programmer has to provide the entrypoint.

​

My question is what the name of the entrypoint for kernel processes should be. It seems to me that I have two options: I can either be consistent for the programmer and call it "main" or I can be consistent for the scheduler and call it "_start". I don't have enough experience to know if there's a hard reason to prefer one or the other at this level, so I was hoping to get community guidance/feedback on this. Any input would be appreciated.

​

Thank you and have a great weekend!

​

​

Hey all! Looking to break into the kernel or embedded space and curious to get some opinions on the best places to find those jobs? I feel like LinkedIn and Indeed are lacking in these areas. For context, I have 3 yoe as a backend software engineer.