Comment by matheusmoreira
2 years ago
I understand what you mean. By dependencies I meant user space libraries such as glibc and musl.
The language itself is fully self-contained. It initializes itself with nothing but a static array of bytes.
Could be possible to modify lone to run on bare metal instead. Perhaps by replacing the Linux system call code with BIOS I/O functions and replacing the Linux process entry point code with boot code that initializes the CPU and hardware.
https://wiki.osdev.org/Printing_to_Screen
That would just shift the dependency from Linux to the firmware though.
>Could be possible to modify lone to run on bare metal instead. Perhaps by replacing the Linux system call code with BIOS I/O functions and replacing the Linux process entry point code with boot code that initializes the CPU and hardware.
Just don't make the mistake golang made. In most systems, the "stable interface to the kernel" isn't the syscall, but the c library.
(re: golang on openbsd)
Absolutely. I've written about this topic and how Linux is different:
https://www.matheusmoreira.com/articles/linux-system-calls
My plan is to target Linux exclusively.
I have always found it absurd that Linux insists on stable syscall ABI, and yet does not have a standard driver API.
Hopefully, the world will migrate to a better system at some point. It will be exactly the opposite: It will not provide a stable syscall ABI, and it will have a standard driver API.
Incidentally, it'll be microkernel, multiserver.
Many articles will then be written about the maintenance burden Linux had, and how we should have done this much earlier.
1 reply →
> Could be possible to modify lone to run on bare metal instead. Perhaps by replacing the Linux system call code with BIOS I/O functions
Certainly not. Calling BIOS interrupts requires the system to be running in real mode, which is incompatible with running 32-bit code.
>Calling BIOS interrupts requires the system to be running in real mode, which is incompatible with running 32-bit code.
Hold my beer[0].
0. https://en.wikipedia.org/wiki/DOS_Protected_Mode_Interface
DPMI is a software interface exposed by an operating system or a DOS extender, not part of the BIOS.
1 reply →
I see. Could it work in protected mode? The OSDev wiki page I linked uses that approach to write to video memory.
> Assuming that you are in protected mode and not using the BIOS to write text to screen, you will have write directly to "video" memory.
I have pretty superficial knowledge about OS development so I should probably refrain from speculating further.
What the OSDev page is describing here:
>> Assuming that you are in protected mode and not using the BIOS to write text to screen, you will have write directly to "video" memory.
... is bypassing the BIOS and interacting directly with hardware. Which is a thing you can do in some circumstances, but it's very limited -- especially if you want to do anything beyond simple console I/O.