zlacker

>>eclipt+(OP)
It looks like golang is going to have to deal with — again — OpenBSD treating libc as the interface with the kernel instead of syscalls being the interface with the kernel.

I wonder if there could be some way to sign a dynamic library to allow it to create direct system calls and then pass that as a kernel command line argument at boot?

>>__turb+3l
OpenBSD is certainly taking it quite far. They want to disallow system calls from all non-libc code segments so that only whitelisted code can interface with it.

It is not the only operating system in the "unstable kernel interface" group though. Linux is actually the only one with a stable system call interface.

I've written somewhat at length about this:

https://www.matheusmoreira.com/articles/linux-system-calls

>>matheu+lp
We need more fat kernels and less libcs, libc ties us forcibly to the C legacy. Time for more type safe and richer interfaces with the kernel.

>>KRAKRI+U21
What do you mean when you say "fat kernel"?

Also, FYI, OpenBSD is never going to stop being written in C, and is never going to introduce a language like Rust into the kernel [1], so there's little point in wishing for this.

If you wish to rid yourself of legacy of C (and therefore that of Unix), then OpenBSD, which is Unix (or derived from it) and will always be written in C, is not a good operating system for you.

Edit: Changed to be less rude; it wasn't my intention to be rude.

[1]: https://marc.info/?t=151233221700001&r=1&w=2

>>treali+0j1
I'm not the person you're replying to, but I don't really mind the kernel (or anything else) being written in C as such, but interacting with C from $other_language can be rather painful for various reasons. In Go the reason they do what they do is because integrating it with how the Go scheduler works is tricky, and getting rid of libc makes cross-compilation a lot easier.

So in short, it's a pragmatic thing more than anything else.

(Aside: that thread is a little bit outdated by the way, as I do believe there's a reasonably complete Rust coreutils implementation now. Not that I think Rust is a good fit for OpenBSD though – I wish people would stop conflating "safety" with "Rust".)