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
> 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.

Something they wouldn't have to do if they'd heeded the warnings they got since they first started going raw syscalls on non linux systems.

But as usual, go is uniquely american, only doing the right thing after it has tried everything else.

>>maskli+Sp
You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI) until the only sane option is removed. Did you know many libc APIs are preprocessor macros?

>>tadfis+qt
> You could also describe it as doing the sane thing (avoiding hardcoding against the libc ABI through FFI)

No, you could not.

On pretty much every system but linux the libc (or equivalent) is the officially supported API to the kernel. Bypassing it is not supported and thus definitionally can not be sane, that's like declaring that doing the sane thing is avoiding hardcoding against the front door and entering your home through the roof instead. The front door is what you're supposed to use, do hardcode against it. Same with libc.

And Go has been going "ouch" then putting its fingers straight back in the socket from the start, as it keeps trying to work around libcs on all the platform where it is not supported.

>>maskli+du
On linux the stable API and ABI that you are supposed to use is also just libc. But due to various reasons people think that the libc ABI is less stable than how stable it really is.

Edit: NT with its split OS API dll and separate libc is its own can of worms. You can have multiple instances of libc in the same address space, which among other things implies that you cannot safely malloc() in one module and free() in another, and don't even think about passing FILE* around.

>>dfox+EV
Linux doesn’t have an official libc. Raw syscalls are its only official API.