3 ms·

So, your argument essentially boils down to "call it something other than libc". Because, most of the syscall integration in libc has little if anything to do w

So, your argument essentially boils down to "call it something other than libc". Because, most of the syscall integration in libc has little if anything to do with C. Eh. Whatever. Call it libunix if you prefer. If you want, you can literally strip libc of anything you don't like, call it libunix, and OpenBSD's ld.so mechanics will gladly pin syscalls to that.

aforwardslash 3y ago
My argument boils down to "there are other views onto implementing userspace runtimes other than the libc view", and "general purpose operating systems should not demand everyone use their own language-specific userland runtime implementation just because its what their favourite language uses". You were the one trying to justify that layer as a de-facto ABI interface. For some things, it is not actually necessary and - in my opinion - should not be the target as a system ABI compatibility. Its a bit like saying "MSVC++ Runtime should be the de-facto runtime for every Windows application". There is a clear distinction between having a posix-compatible POSIX system (which targets source-code portability, focused mainly on C as the lowest common denominator) or a System V compatible system that provides POSIX compatibility. > Eh. Whatever. Call it libunix if you prefer. It is not not "whatever". A language-specific library should not - in principle - be a core dependency of every userland application on a general purpose UNIX system; A given language may implement its own runtime, as well as provide pure statically linked binaries. You may have a different opinion, but it seems a bit childish to discard the fact that not only there are use cases, but this has been somewhat of a problem in the past just because you don't agree with it. No one is stopping you from using libc.
- nanolith 3y ago
  You want to impose your Linux-centric view of ossified syscall ABIs on the world. That's just not reality on any other operating system other than Linux, nor should it be. libc is the standard, but there is nothing that prevents you from hacking up libc to make some Frankenstein library that makes you feel better about "avoiding C" for whatever that's worth. Somehow, you think that libc is making your language runtime worse because it's written in C. Somehow, you think that writing an FFI -- as most high level languages do -- into libc is an inconvenience. It will probably blow your mind to realize that most operating systems, and thus most syscall interfaces, are also written in C. :-) Then you compare libc to the MSVC++ runtime for some odd reason. And yet, if you do write applications that target Windows, you use their system libraries, which are predominantly written in C and provide C functions, regardless of the high level language you choose. These libraries implement the interface to the kernel, much like most operating systems other than Linux.
  - aforwardslash 3y ago
    > You want to impose your Linux-centric view of ossified syscall ABIs on the world. That's just not reality on any other operating system other than Linux, nor should it be. Actually, its not linux-centric, its System V-centric. And there is no ossification - at least not more than you have on what you're defending - a standard userland ABI runtime. I'm assuming you actually never used older systems - syscall/interrupt-based/call gate based is actually the "the facto standard", not whatever libc-based system you're running. I also find it amusing you keep talking about linux. Did Linus eat your homework or something? For me it is quite odd, specially considering I've been using OpenBSD since 2.9, FreeBSD since 4.3 and only somewhat recently use linux as a main unix-compatible environment. > libc is the standard Says you and nobody else. Case in point, the problem is with a runtime that IS NOT libc-based, and should be supported, because it is targeting a SPECIFIC OS VERSION and not a libc version. Btw, that's why OpenBSD has its support cycles measured in releases, and not libc versions, but I'm assuming you are completely aware of this. > Somehow, you think that writing an FFI -- as most high level languages do -- into libc is an inconvenience. It will probably blow your mind to realize that most operating systems, and thus most syscall interfaces, are also written in C. :-) Yes, we - the rational people that think a general-purpose operating system should not be dictating runtimes onto users - we are all stupid, and we never did any OS-related development. We also fail to realize that C is basically the lowest common denominator, that's why its used as a semi-stub language for machine-level stuff. We are very very stupid here in the land "we are not you". Is that it? > And yet, if you do write applications that target Windows, you use their system libraries, which are predominantly written in C and provide C functions, regardless of the high level language you choose Well, yes and no. Last time I checked, any 32 bit assembly application using int 21h is honored (haven't tested it on 64 bit), ~40 YEARS ON. Same goes for DPMI calls. That's the "syscall layer" for you. You may also be surprised to find out that Windows is actually a sort of hybrid microkernel (such as macos X family, btw), so you can actually provide a lot more "core functionality" as part of the base OS, such as audio mixing or graphics primitives. and you can use the "fancy approach" and use an available runtime (MSVC++ IS an example of a runtime similar to libc), or use your own. The last semi-monolithic version of it was Windows ME, and the lowest common denominator for operation is - you guessed it - system interrupts. Your console app developed in 1999 in Windows ME should run fine on a modern Windows version, as it will your OpenBSD console app, as long as you don't depend on libc. In fact, your 1983 MSDOS app should have no problem running in a fairly recent version of Windows without any kind of emulation whatsoever, except for the v86 wrapping mode. Oh and no, I'd say most windows core libraries are C++, not C. And even there, they're trying to get rid of it for - AT LEAST - 20 years - many internal services in Longhorn were C#. Things evolve, and the sooner we get rid of the C heritage, the better. > These libraries implement the interface to the kernel, much like most operating systems other than Linux. Your simplistic view of operating systems based on what OpenBSD is amuses me. As an example, feel free to ping me back when your userland kernel ABI actually implements useful stuff like a unified audio interface (or linux, since you mention it so much). Or volume management. Or actually unified printing experience. You know, all the stuff you actually get from microkernel or hybrid-based kernels that you DON'T have in monolithic kernel design. Have libc doing something that isn't either a runtime library for your specific language or a syscall and you may have a point. Until then, its actually quite more restrictive than using int-based syscalls. Note: edited for formatting

aforwardslash 3y ago

My argument boils down to "there are other views onto implementing userspace runtimes other than the libc view", and "general purpose operating systems should not demand everyone use their own language-specific userland runtime implementation just because its what their favourite language uses". You were the one trying to justify that layer as a de-facto ABI interface. For some things, it is not actually necessary and - in my opinion - should not be the target as a system ABI compatibility. Its a bit like saying "MSVC++ Runtime should be the de-facto runtime for every Windows application". There is a clear distinction between having a posix-compatible POSIX system (which targets source-code portability, focused mainly on C as the lowest common denominator) or a System V compatible system that provides POSIX compatibility. > Eh. Whatever. Call it libunix if you prefer. It is not not "whatever". A language-specific library should not - in principle - be a core dependency of every userland application on a general purpose UNIX system; A given language may implement its own runtime, as well as provide pure statically linked binaries. You may have a different opinion, but it seems a bit childish to discard the fact that not only there are use cases, but this has been somewhat of a problem in the past just because you don't agree with it. No one is stopping you from using libc.

nanolith 3y ago
You want to impose your Linux-centric view of ossified syscall ABIs on the world. That's just not reality on any other operating system other than Linux, nor should it be. libc is the standard, but there is nothing that prevents you from hacking up libc to make some Frankenstein library that makes you feel better about "avoiding C" for whatever that's worth. Somehow, you think that libc is making your language runtime worse because it's written in C. Somehow, you think that writing an FFI -- as most high level languages do -- into libc is an inconvenience. It will probably blow your mind to realize that most operating systems, and thus most syscall interfaces, are also written in C. :-) Then you compare libc to the MSVC++ runtime for some odd reason. And yet, if you do write applications that target Windows, you use their system libraries, which are predominantly written in C and provide C functions, regardless of the high level language you choose. These libraries implement the interface to the kernel, much like most operating systems other than Linux.
- aforwardslash 3y ago
  > You want to impose your Linux-centric view of ossified syscall ABIs on the world. That's just not reality on any other operating system other than Linux, nor should it be. Actually, its not linux-centric, its System V-centric. And there is no ossification - at least not more than you have on what you're defending - a standard userland ABI runtime. I'm assuming you actually never used older systems - syscall/interrupt-based/call gate based is actually the "the facto standard", not whatever libc-based system you're running. I also find it amusing you keep talking about linux. Did Linus eat your homework or something? For me it is quite odd, specially considering I've been using OpenBSD since 2.9, FreeBSD since 4.3 and only somewhat recently use linux as a main unix-compatible environment. > libc is the standard Says you and nobody else. Case in point, the problem is with a runtime that IS NOT libc-based, and should be supported, because it is targeting a SPECIFIC OS VERSION and not a libc version. Btw, that's why OpenBSD has its support cycles measured in releases, and not libc versions, but I'm assuming you are completely aware of this. > Somehow, you think that writing an FFI -- as most high level languages do -- into libc is an inconvenience. It will probably blow your mind to realize that most operating systems, and thus most syscall interfaces, are also written in C. :-) Yes, we - the rational people that think a general-purpose operating system should not be dictating runtimes onto users - we are all stupid, and we never did any OS-related development. We also fail to realize that C is basically the lowest common denominator, that's why its used as a semi-stub language for machine-level stuff. We are very very stupid here in the land "we are not you". Is that it? > And yet, if you do write applications that target Windows, you use their system libraries, which are predominantly written in C and provide C functions, regardless of the high level language you choose Well, yes and no. Last time I checked, any 32 bit assembly application using int 21h is honored (haven't tested it on 64 bit), ~40 YEARS ON. Same goes for DPMI calls. That's the "syscall layer" for you. You may also be surprised to find out that Windows is actually a sort of hybrid microkernel (such as macos X family, btw), so you can actually provide a lot more "core functionality" as part of the base OS, such as audio mixing or graphics primitives. and you can use the "fancy approach" and use an available runtime (MSVC++ IS an example of a runtime similar to libc), or use your own. The last semi-monolithic version of it was Windows ME, and the lowest common denominator for operation is - you guessed it - system interrupts. Your console app developed in 1999 in Windows ME should run fine on a modern Windows version, as it will your OpenBSD console app, as long as you don't depend on libc. In fact, your 1983 MSDOS app should have no problem running in a fairly recent version of Windows without any kind of emulation whatsoever, except for the v86 wrapping mode. Oh and no, I'd say most windows core libraries are C++, not C. And even there, they're trying to get rid of it for - AT LEAST - 20 years - many internal services in Longhorn were C#. Things evolve, and the sooner we get rid of the C heritage, the better. > These libraries implement the interface to the kernel, much like most operating systems other than Linux. Your simplistic view of operating systems based on what OpenBSD is amuses me. As an example, feel free to ping me back when your userland kernel ABI actually implements useful stuff like a unified audio interface (or linux, since you mention it so much). Or volume management. Or actually unified printing experience. You know, all the stuff you actually get from microkernel or hybrid-based kernels that you DON'T have in monolithic kernel design. Have libc doing something that isn't either a runtime library for your specific language or a syscall and you may have a point. Until then, its actually quite more restrictive than using int-based syscalls. Note: edited for formatting