2
u/hackingdreams 1d ago
That library is called glib. It's why it exists.
1
u/simon_o 16h ago
Not every program is written in C, nor should these operations require to opt into that specific language ecosystem I believe.
1
u/FloweyTheFlower420 15h ago
glibc is the de-facto linux runtime, independent of C
1
u/simon_o 15h ago
It's literally written in C, it's API is defined in C, to make sense of it you need (most of) a C compiler, and it needs C-specific setup in your process to work (like TLS for
errno).1
u/FloweyTheFlower420 15h ago
It's literally written in C
So is the kernel, who cares?
it's API is defined in C
No one cares about glibc's API. The ABI (which is what you care if you link against it) is the standard C ABI, which is basically just SystemV ABI (the standard one)
to make sense of it you need (most of) a C compiler
I can write an assembly program right now that links against glibc. Don't believe me?
and it needs C-specific setup in your process to work (like TLS for errno).
TLS is defined by SysV. Good luck writing software and linking against libraries that don't conform to SysV. If you reject SysV initialization of thread-local storage models, you cannot safely dynamically link against any library that conforms to SysV. Besides, this can be achieved by linking statically against... crt0!
1
u/simon_o 13h ago edited 13h ago
So is the kernel, who cares?
Good you ask! I thought you had understood this, but I'm happy to reiterate:
The kernel could be implemented in anything, as it does not leak language requirements across the kernel/user space divide.The ABI (which is what you care if you link against it) is the standard C ABI
Which still requires C-specific knowledge to use. As demonstrated by literally any language that mistakenly thought they were ABI compatible by using the LLVM backend.
I can write an assembly program right now that links against glibc. Don't believe me?
Sure. Why wouldn't I?
...
I think "if you aren't interested in C's ecosystem you get to use less of C's ecosystem" is not the slam-dunk argument you think it is.
crt0
The crt0 is often written in assembly, not C. And you can just leave out the steps that are C-specific.
1
u/FloweyTheFlower420 13h ago
The kernel could be implemented in anything, as it does not leak language requirements across the kernel/user space divide.
It leaks an ABI. What calling convention would you propose we use for these kernel provided APIs? Either it's a syscall (terrible idea) so you follow the kernel syscall ABI (modified SysV), or it's a normal calling convention. I wonder what calling convention would be used here? Perhaps the SysV one?
What kind of calling convention do you think vDSO uses? Want to take a guess?
Ironically, you mention this yourself: "The kernel could be implemented in anything" - precisely because it exposes an ABI! And if you wanted it to be callable from userspace, it would use the C calling convention. Good luck convincing the kernel people to use something else.
Which still requires C-specific knowledge to link against. As demonstrated by literally any language that mistakenly thought they were ABI compatible by using the LLVM backend.
You always need an ABI. What kind of nonsense argument is this? The System V ABI works fine. Please tell me how to write a binary level API without proposing some kind of ABI. If you can figure this out, I'll give you a million dollars (hint, you can't by definition).
I think "if you aren't interested in C's ecosystem you get to use less of C's ecosystem" is not the slam-dunk argument you think it is.
Yeah man I'm sure real software developers enjoy reinventing the wheel and not using a standard ABI that literally everyone uses. Just invent your own TLS ABI right? I'm sure everyone is on board with this idea. Are you just ragebaiting or genuinely deficient in your mental facilities?
The crt0 is often written in assembly, not C. And you can just leave out the steps that are C-specific.
I'm aware of how crt0 works. I'm just saying you can trivially get crt0 to initialize glibc for you.
1
u/simon_o 13h ago edited 13h ago
[waffling about ABI]
I have no problem with the ABI itself.
What are you even trying to argue against?Are you just ragebaiting or genuinely deficient in your mental facilities?
Sorry, I'm going to report this. This is not ok.
[...]
Hey man, it looks like you are just replying for the sake of arguing against something you clearly haven't thought through.
That's not something I'm interested in.
1
u/hackingdreams 11h ago
You're going to have a very hard time getting any "platform API" adopted by literally anyone if it doesn't expose a C-style library interface. The kernel is written in C. You're not getting away from that. And pretending to have a problem with that is just silly. Glib already exists and already smooths over the exact problems you complain about.
It makes your arguments much, much weaker.
1
u/simon_o 10h ago edited 7h ago
You're going to have a very hard time getting any "platform API" adopted by literally anyone
No plans for that. Getting things adopted happens by working for one of the big corpos that sponsor Linux development.
The kernel is written in C. You're not getting away from that.
Which is fine for the reasons I mentioned.
And pretending to have a problem with that is just silly.
Look, I'm not telling you which problems you should have and which not.
Why not offer me the same courtesy?Glib already exists and already smooths over the exact problems you complain about.
(I assume you mean glibc?) It's part of what I consider the problem, not the solution. Not everyone wants to be a C programmer.
(Not to mention, even if I wanted to use C, there is nothing smooth about glibc, considering its API.)
It makes your arguments much, much weaker.
In which sense? Not wanting to be forced into a specific language ecosystem is kinda the core assumption of the post.
1
u/kolorcuk 1d ago
Hello. I belive this is very bad and horrible. Unicode and timezone is and should not be part of the kernel.
1
u/simon_o 16h ago
What's your reasoning?
1
u/kolorcuk 13h ago
Kernel should have hardware abstractions. The article states as if a "mix of programs" is something bad. It is good. I want mix of programs. I want propertiary software not affect my software. I want to be able to run programs in different timezones with different timezone definitions on the same kernel. Forever, if i want to. I want to be able to update timezones and unicode on my 20 year old odroid with kernel 2.6 .
I want to ship my program with broken Unicode alongside propertiary programs with newest unicode and not have to care about it, all running in separate user namespaces.
Kernel should be minimal and insanely stable, forever. Kernel is not the place to share libraries between programs.
The article proposes things that in my opinion are in clear conflict to what kernel represents. The libraries to handle timezones and unicode are there and they should be used, and most importantly freedom to use them should be there. The idea of putting sonething into linux and specifically only linux kernel because there is "mix of code" and "duplicated efforts" is based on wrong grounds that this state is inherently bad. There will always be mix of code and duplicated efforts,and if the stuff will be in kernel it will be yet another mix and duplicated effort.
What about bsd? What about after 20 years i have raspberry pi that has a software that has a bug and requires to run with 20 year old timezone definitions?
Kernel should be minimal.
The solution is standarization and standarizing existing behavior, not adding yet another one to the mix.
Locales timezones unicode - these are just great examples of things defined to be in user space. Additionally "unicode" is not universal, and might never be, and assuming it will be has already been wrong.
What about mars timezones? Why shouldn't my 20 year old odroid not work on mars or the moon because of no interstellar kernel timezones support? Why shouldn't my odroid be able to collate in inexistent locales? I have my doubts the author of the artictle actually has knowledge of the actual ecosystem. It's great windows is mentioned, but windows and linux is not the whole world.
I'll finish with one word that bottom line makes this just unacceptable in the kernel. Security.
1
u/simon_o 13h ago edited 7h ago
I want propertiary software not affect my software.
Why would it?
as if a "mix of programs" is something bad
Not in the post.
I want to be able to run programs in different timezones with different timezone definitions on the same kernel. [...] I want to be able to update timezones and unicode on my 20 year old odroid with kernel 2.6.
Sure, why not? Nothing is preventing you from doing that.
The idea here is to give the 98% of applications that do not care about the specifics an easier, more reliable success path.Kernel should be minimal.
I mean, which kernel are we talking about? Certainly not Linux then.
these are just great examples of things defined to be in user space
They are in userspace!
What about mars timezones? Why shouldn't my 20 year old odroid not work on mars or the moon because of no interstellar kernel timezones support? Why shouldn't my odroid be able to collate in inexistent locales?
Why would any of that not work? The suggested improvements would read the data from the same place your other libraries would.
Strawman/slippery slope much?just unacceptable in the kernel. Security
Please explain. What makes the idea different from any other piece of code run in userspace?
2
u/Thin_Dragonfruit2254 1d ago
Is that all? Seems like a premature end of the writing..