Kernel written in bytecode

[vlad9486]

There are some operating systems written in a managed language that translates to bytescode, like Java or .NET.

The following is a joke, but maybe we should take it seriously. Linux is such an OS. It is written in... ELF. Regardless, it is non-Turing complete, but it is bytecode, it tells the computer what to do. Namely, it tells it what to load and where to put program sections. This bytecode allows machine code insertions, making it turing-complete. The Linux kernel is an interpreter of ELF bytecode. Of course, it is much more than that, but it could just be the interpreter of ELF.

I just wanted to say that declarative language is very helpful. And the line between OS written in machine code and OS written in managed code could be blurred. We can mix some bytecode (even non-Turing complete) and machine code. There are many such examples: ELF, devicetree (.dts), systemd unit files, kubernetes .yaml configs. They are all OS related and declarative code/config, they could all be replaced by some declarative language, and OS could be written in that language in the same sense as Linux is written in ELF.

[iansjack]

Surely if Linux were bytecode it would be architecture agnostic?

[vlad9486]

ELF is architecture agnostic. But it contains machine code insertions which are not.

[iansjack]

Those are pretty big “insertions”.

Elf is a container for the code, not the code itself. It’s not even architecture agnostic. The header contains entries specifying the processor and the target os ABI. This is not bytecode like, for example, SmallTalk or Java where you just need a machine specific virtual machine to run the same code.

[rdos]

ELF is an executable format, not code. The OS machine code is created by the compiler and then the linker encapsulates the code into ELF format. IOW, the ELF format is not used by the CPU at all.

[vlad9486]

ELF is an executable format, not code. The OS machine code is created by the compiler and then the linker encapsulates the code into ELF format. IOW, the ELF format is not used by the CPU at all.

That's why I wrote

The following is a joke

Of course ELF is not used by the CPU in some sense. In the same sense Java bytecode is not used by the CPU at all.

[vlad9486]

Those are pretty big “insertions”.

Elf is a container for the code, not the code itself. It’s not even architecture agnostic. The header contains entries specifying the processor and the target os ABI. This is not bytecode like, for example, SmallTalk or Java where you just need a machine specific virtual machine to run the same code.

Sure, it cannot do what ordinary code does. But the software (Linux kernel) interprets like Java interprets Java bytecode. It teach us that there is a space between cases: "Kernel is an interpreter of Java plus some Java code" and "OS is written in C without any interpretation"

[AndrewAPrice]

A kernel is just an executable file, as you suggested. You could for sure compile it to bytecode, but how will you bootstrap and execute it?

Does your bootloader load a "stage 2 loader" that interprets or JITs the kernel? If the bytecode is high level and the VM managers threading, context switching, memory management, etc, then who is the actual kernel? Probably the VM!

[rdos]

Those are pretty big “insertions”.

Elf is a container for the code, not the code itself. It’s not even architecture agnostic. The header contains entries specifying the processor and the target os ABI. This is not bytecode like, for example, SmallTalk or Java where you just need a machine specific virtual machine to run the same code.

Sure, it cannot do what ordinary code does. But the software (Linux kernel) interprets like Java interprets Java bytecode. It teach us that there is a space between cases: "Kernel is an interpreter of Java plus some Java code" and "OS is written in C without any interpretation"

Wrong. The Linux code is written in C (mostly) without any interpretation. What a loader of ELF files does is to potenitally fixup addresses in the image. That has nothing to do with interpretation. So, the Linux kernel is not in between Java and C. It is C without any form of interpreration.

In my kernel, syscalls are invalid calls and are fixed up in GPF handler by creating call gates and patching the code. This is not interpretation, just linking a call to the proper entrypoint. In kernel, device drivers define their entrypoints, and when another driver use them, an invalid call in the code is patched by GPF handler to a far call. That is similar to fixing up addresses in ELF, and is not interpretation.

[vlad9486]

@rdos You are arguing about worlds meaning. Ok, let you call it whatever you like. Your example doesn't involve declarative code. But my point is that Linux apps contain some declarative code that Linux parses and do something with it (call it interpretation or whatever).

[iansjack]

All apps on all devices contain “declarative code that the operating system parses”. To call this “bytecode” is to totally devalue the term. The whole point of bytecode is that the same file is machine independent and will run, without changes on many architectures. It is a disservice to ignore the very quality that distinguishes bytecode from an executable developed for a particular architecture.

Yes, that is “arguing about words meaning”. Meaning is important - it gives language the ability to communicate ideas.

[rdos]

Yes, many apps and the kernel itself will parse arguments, configuration files and things like that, but it has nothing to do with ELF or byte code. ELF is an executable format and does not contain configuration. In a kernel it's at most used for relocation. Perhaps the most important thing about ELF is that it can contain debug information so you can debug code at source level.

[vlad9486]

Yes, that is “arguing about words meaning”. Meaning is important - it gives language the ability to communicate ideas.

Exactly! Meaning is important only if it helps communicate the idea. Your and @rdos answers completely ignore my idea and focus on the meaning of the words. So meaning doesn't help in this case.

[iansjack]

I ignore your idea because it is built on the false premise that an elf executable file is bytecode.

Call it an elephant if you like, it’s still not a bush baby.

[vlad9486]

I ignore your idea because it is built on the false premise that an elf executable file is bytecode.

Call it an elephant if you like, it’s still not a bush baby.

1. The idea isn't built. If I had a complete idea, I would write a paper about it, or just quietly implement it. Forum exists to discuss some vague thoughts and undeveloped idea to build it.
2. The idea has nothing to do with what ELF is. I know what ELF is. That's why I wrote "the following is a joke". This is the way to understand the idea. Trying to think seriously about the joke while ignoring it's obvious falseness. Sometimes new ideas lack words to describe them. So I have to misuse existing words.
3. If you don't like the idea, or don't find it interesting, or don't want to make the intellectual effort to try to take the joke seriously. You can just not bother to comment on it. Simple as that!
4. I don't ask what ELF is. I don't need you to tech me. There is another forum section for that. This section is for sharing and discussing something new.