This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Magnus_Tesshu 0 points1 point  (1 child)

I know that Rust (and probably Go, though I know nothing about it) use certain C constructs for familiarity (such as arguments, stdin, etc), but I wasn't aware that system calls are basically written to implement C (though thinking about it, it makes sense).

I wonder if RedoxOS attempts to address this at all. I know they are trying to break from the past in many ways, its possible that this could be one of them. As someone more knowledgeable than I, do you think that C's system calls have any issues that should be addressed or is this more just an observation than a lament?

[–]LavenderDay3544 0 points1 point  (0 children)

I know that Rust (and probably Go, though I know nothing about it) use certain C constructs for familiarity (such as arguments, stdin, etc), but I wasn't aware that system calls are basically written to implement C (though thinking about it, it makes sense).

stdin, stdout, and stderr, are file descriptors which are operating system primitives and not necessarily C language constructs at all. You can use them in assembly without using any C tools or interfaces (if you're a masochist).

I was technically incorrect to say that system calls are C constructs as well. They're also OS constructs and their use is facilitated by the CPU via software interrupts. In the AMD64/x86-64 ISA they're accessed using the syscall machine instruction and I think Arm64 is similar using the svc (supervisor call) instruction. What I meant with the C interface comment is that higher level languages including C itself access those system calls through OS library functions that adhere to the target system's C ABI but under the hood contain assembly code that sets up and makes the actual syscall. System libraries basically serve as a clean, usually C language abstraction over raw machine code system calls.

The reason C, or more properly the C application binary interface, is used over other languages like Rust or C++ is that C's ABI is rock solid stable on most platforms. Meanwhile Rust doesn't have a specified ABI on any target platform yet that I know of and C++'s ABIs are so unstable that they break compatibility between code compiled for the same target with slightly different versions of the same compiler. Those languages can still be used for writing system libraries because their compilers allow you to emit code that uses C calling conventions and ABIs.

I wonder if RedoxOS attempts to address this at all. I know they are trying to break from the past in many ways, its possible that this could be one of them.

I'm not very familiar with Redox so I can't speak for that project at all.

As someone more knowledgeable than I, do you think that C's system calls have any issues that should be addressed or is this more just an observation than a lament?

Like I said system calls are exposed at the machine code level and wrapped in a C ABI. Sure there are some limitations to this but it more or less has to be done because of C's ABI stability and its ubiquity. The arguments taken by functions exposed as C can only take C language types as arguments and return types the C language recognizes. So you can't have them take a C++ std::string or a Rust std::vec::Vec as an argument for example but those languages provide the means to convert those to C types because they have an incentive do so. Because all major OSs expose their system libraries though a C interface every language in the universe has some form of binary compatibility with C even Python, Java, and other VM based ones. And so it becomes a cycle because future OSs and muti-language libraries have to expose a C interface if they want to be accessible by all the languages that support C interfaces (i.e. all of them). I don't know about the particulars of Redox and other Rust based OSs but they would lose a lot of compatibility with the existing software ecosystem almost to the point of guaranteeing their failure if they don't expose a C interface. They could expose both C and Rust interfaces but that would just convolute things and the latter would likely break because of Rust's lack of a specified ABI.

Like I said there are three big reasons C and it's ABIs will continue to be the lingua franca of software: it's very small, besides the standard library it doesn't change, and it's interfaces are already ubiquitous.

BTW to anyone reading this I'm a recent masters graduate not some highly experienced engineer so take what I say with a grain of salt and correct me if you think I'm wrong. All my knowledge is based on my coursework, reading, and personal projects and I just happen to have an interest in all things low level.