zlacker

[return to "OpenBSD: Removing syscall(2) from libc and kernel"]
1. __turb+3l[view] [source] 2023-10-27 17:00:14
>>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?

◧◩
2. saagar+ft[view] [source] 2023-10-27 17:38:49
>>__turb+3l
I am sure Cosmopolitan is going to love this change.
◧◩◪
3. maskli+wu[view] [source] 2023-10-27 17:46:40
>>saagar+ft
I would assume they already have ways to bounce through a dynamically linked system library since cosmopolitan works on macos, and even more so windows.
◧◩◪◨
4. Consca+zm1[view] [source] 2023-10-27 22:40:57
>>maskli+wu
That's true, but it's a point of pride in Cosmo's marketing that it produces statically linked binaries acroscreate, least several operating systems.

It can dynamically link the system32 DLLs in Windows and probably could OpenBSD's crt, but dynamic linking in general doesn't work. `dlopen` is no-op, and this has made Cosmo graphics extremely difficult so far.

◧◩◪◨⬒
5. action+fo1[view] [source] 2023-10-27 22:53:11
>>Consca+zm1
Is that a self-imposed limitation? It sounds eminently possible to add some kind of work-around for dynamic linking. Maybe not for a general case, but for creating a GUI for instance.
◧◩◪◨⬒⬓
6. Consca+dv1[view] [source] 2023-10-27 23:55:19
>>action+fo1
Yes, there actually is a to-be merged fork of Cosmopolitan that makes Dear ImGui work, but no dynamic linking is generally a big limitation for GPU acceleration.
[go to top]