[notaplumber]

> I modified the OpenBSD kernel for the raspberry pi with gaming related extensions, in such a way that when the game runs there is no latency and no stuttering.

What does that even mean? What "gaming related extensions"?-- could you elaborate?

OpenBSD doesn't have any accelerated drivers for the GPU on the RPi, so I'm curious what your "no latency/no stuttering" modifications would even be, beyond perhaps maybe recompiling the kernel with HZ=1000 or something else..

[alehyze]

Without going into the details: I have read the linux drivers and understood how HDMI audio and hardware sprites (planes) work amongst other details. Then implemented that myself in C and assembly with no OS. Then modified the OpenBSD kernel in a way that it can use that stuff and do even more sophisticated stuff. This is not just recompiling the kernel with some different options. It's writing substantial code. I modified 6.8 because 6.9 was not even out when I started, so it's been a couple of months of very hard work on the kernel only, not counting all the time I spent on it before when I was working bare metal. And it's not finished yet :-)

[notaplumber]

This is HN, I'm sure people would appreciate hearing the details. Like how does this integrate with OpenBSD's existing audio/graphics stacks, do you plan to upstream your work? With it being OpenBSD, are there security implications?

[dr_zoidberg]

Well, he did say he wants to turn that into a product, so I understand he won't release details as they are a form of trade secret for his idea.

[alehyze]

I just released the "big picture". I am sure that the OpenBSD kernel devs can redo what I did ten times quicker (in terms of development time) and a million times better (in terms of clean integration with the kernel and security) if they want to. They know all of the details of the kernel :-)

That said yes, I would like to be able to turn this into a product.

[SLWW]

I'm interested in this; though i struggle to understand how you could turn something like this into a product.

There's a lot of logistics in selling this type of thing. Also the BSD license isn't exactly easy to sell something alongside of.

Have you considered open-sourcing and doing the ol' "if you like my work, buy me a coffee"

I know it's extremely communist of me, but I just can't imagine you not stepping on a lot of toes (both legally and otherwise) because of the spirit that OpenBSD was written in.

[ac29]

> BSD license isn't exactly easy to sell something alongside of

Why's that? There's no reason you cant have a closed-source commercial fork of BSD code. The Playstation 4 OS is a fork of FreeBSD: https://en.wikipedia.org/wiki/PlayStation_4_system_software

[alehyze]

I haven't thought this through I have to admit.

I thought that the BSD license was friendly to this kind of stuff.

If I step on people's toes I would ask for forgiveness and try to give them something back, which I think is just the right thing to do.

For example, I read that OpenBSD developers were sad that most of the contributions they got was from individuals more than from companies, when they actually help companies a lot.

Maybe this could be a way to change that situation?

At the end of the day I want to be happy with myself. I don't want to make enemies. Possibly, I would love to keep working on this for a living as I enjoy it more than everything else I did in the past.

This is not a product yet. If it's going to be, it's going to be a very long and hard way before that happens. Why is everyone so concerned about money at this stage?

Personally, I thought that this was a cool thing that some people would like. Maybe I could make a simple living out of it.

Most people comments seem to me like they are assuming that this is going to be a huge success that could make money and are worried that the other devs would be left out with nothing.

Isn't this a bit of a prejudice? And isn't it premature to assume it's going to be a success?

[alehyze]

What it does at the moment is a bit hacky, in that it does not integrate with the existing graphics stack in the way people could think.

I haven't written a driver for the pi graphics card or for HDMI audio. What I do with graphics is to save the existing state before beginning the game, do whatever I want during the game and restoring the state when it ends. With audio I am not doing it that cleanly as I believe that OpenBSD does not currently even touch HDMI audio registers.

As for the reduction of stuttering, when the game begins I stop 3 of the four cores, assign them entirely to the game ( also with new interrupt vector tables both in EL0 and EL1 ) and when the game exits give them back to OpenBSD. That way, while the game is running without interruption, the single core that is left to OpenBSD is free to run admin tasks. Since the game has a process that can be scheduled by that single core, the game can do networking or file I/O using OpenBSD, because the different cores have the same entries in the user space MMU tables and so they share memory and can talk to each other. OpenBSD cannot interrupt the game, it can only kill it if needed.

Regarding upstreaming my work the answer is "Probably not. But if the world wants it open sourced I am not against it and could think about doing a fork (Say we call it OpenBSD4Games). Or I could just give some help with the raspberry pi drivers."

The reason for that is that I am doing quite some stuff that am pretty sure the OpenBSD devs would not be happy to put in. OpenBSD is strongly focused on security. I am pretty sure they would not want to have some code in there that hijacks 3 cores out of 4 and gives them to a user process. Another example: I have been told that giving several contiguous memory pages to a user task is something that should not be done in OpenBSD. I understand why but then I give a game quite a few contiguous memory pages that the hardware will use for the frame buffer and so has to be contiguous.

Also, this is prototype code. It works for me, it still needs a ton of work and might not even be 100% correct. I cannot possibly understand all of the little details in the kernel in 2 months.

I am proud of this achievement though and would love to be able to turn this into a real product that many people enjoy.

Regarding the "home computer" part, I thought about game devs. When doing a game, it's not only the game code that is important. The tools are very important as well. So I built GNUstep ( on OpenBSD it does not currently work on arm64 ) so that it's super easy to build tools for game development in Objective-C.

Also I thought about playing around and experimenting, and I am planning a GUI app with GNUstep that integrates a C/C++ interpreter called cling, which is developed by CERN for their physics simulations if I am not wrong. With that, a game developer will be able to experiment with code and tweak it in a way that is similar to what Xcode playgrounds does with swift on the Mac.

[alehyze]

By the way, here is a video demonstration of all this. It's not very polished and VSYNC does not work, but it works pretty much how I describe here.

https://youtu.be/KhRnGbVhejk

[MonkeyClub]

Kudos to you, that's very interesting!

Could you share any resources you used to understand, navigate, and extend the OpenBSD kernel?

There doesn't seem to be much in the way of resources available on that -- nothing like the NetBSD Internals guide, not to mention the wealth of information on the Linux kernel.

A blog post on that would probably be widely appreciated as well, if you have the time :)

[alehyze]

Thanks :-)

The article that got me started is the pdf taken from a conference called "OpenBSD Kernel Internals: The Hitchhiker's Guide" mentioned here: https://www.openbsd.org/events.html

I just checked the link and the site seems to be down for me now, so I refer you to that page. Hopefully it will come back up or the link will be updated.

In that article it describes how to add a syscall to openbsd. So you start by writing a very simple one just to see that it works and get comfortable rebuilding the kernel and testing your syscall with a userspace program.

Then, since I roughly knew what I wanted to achieve, I started looking at kernel code and finding the parts relevant to what I wanted to do.

Then take baby steps with your changes, try and fail until you succeed with a small bit before moving on to the next. Especially value failures, as they give you hints about what is going on. Think why it could have failed and try a different approach that should not fail in the same way. Very tedious and time consuming, but a very good way to learn when you don't have the books.

Then looked for hints on the web and talked to the awesome people on the mailing lists and on the reddit OpenBSD channel.

I did not talk too much to people though, I asked a few questions at the beginning and then had a short conversation about allocating contiguous physical memory to a userspace task, which is something that OpenBSD does not do. I figured out how to do that by myself, by trial and error. Same with other details.

My mindset was: I know how to do this with bare metal, there must be a way to connect to the kernel code and do the same in a way that does not break things too much if I keep it limited in scope.

I hope this helps :-)

[MonkeyClub]

Yep, this is quite nice and helpful, many thanks!

[alehyze]

:-)