OSDev.org

Hi!

Recently, I've reached with a OS-model problem. That is, with the ELF loader and friends. I've read that the Linux Kernel has them integrated, but why? Shouldn't they be separate modules? I understand this is an advantage on Panics/Booting, but please give me the pros/cons of integrating them inside the kernel file itself.

A Linux module is an elf file. So, can you foresee a problem if you make the elf loader a module? In any case, what would you gain by doing so?

As far as I am concerned, my Linux kernel is configured so that anything I am sure to need, e.g. a driver for my NIC, is compiled into the kernel. Stuff that I may or may not need, e.g. a FAT filesystem handler, is compiled as a module.

KemyLand wrote:Hi!

Recently, I've reached with a OS-model problem. That is, with the ELF loader and friends. I've read that the Linux Kernel has them integrated, but why? Shouldn't they be separate modules? I understand this is an advantage on Panics/Booting, but please give me the pros/cons of integrating them inside the kernel file itself.

Hmm, I cant really see huge advantages/disadvantages of either situation, I think it depends on your kernel design
My OS for example has a implementation in the kernel for loading the initial binaries, and then the spawner process is running as a program in userspace that has the rights to access specific kernel calls.

KemyLand wrote:Hi!

Recently, I've reached with a OS-model problem. That is, with the ELF loader and friends. I've read that the Linux Kernel has them integrated, but why? Shouldn't they be separate modules? I understand this is an advantage on Panics/Booting, but please give me the pros/cons of integrating them inside the kernel file itself.

For my design which is a microkernel like design, the kernel has no knowledge about the elf-format. The boot loader has a simple elf loader and when it is up and running a user space program called the program manager has the elf loader capability. The advantage is to keep the kernel simple and also the possibility to change to any type of file format.

When the system is up and running in Linux, much of the elf loader for user space programs is actually done in user space as well by the dynamic linker. I'm not sure how much kernel elf is involved here.

How do you plan to execute modules if your kernel doesn't natively support any executable formats?

If you want to keep your core kernel very small, it could be little more than an initial ramdisk parser. Your bootloader loads the initrd and the kernel finds and jumps to a flat binary whose only job is to load modules. Although, I wouldn't really call this a kernel - it's more like an nth stage bootloader, really.

Also, one problem you might have with using a flat binary is that it exports no symbols so you will have a hard time passing messages between it and your kernel. You could add your own symbol tables, allowing your kernel and ELF loader to interact, but then you've just got a non-relocating executable loader, so you might as well go the whole nine yards and put the full ELF loader and dynamic linker in your kernel.

My advice is to pick your favourite executable format (ELF, PE, MACH-O, ...) and write a parser for that format, but try to separate the executable parsing step from the loading and linking steps so that you can write parsers for more formats later, and invoke the existing dynamic linker. AFAIK Linux is quite tightly-coupled with the ELF format and it's not trivial to write a module that allows loading e.g. PEs.

You could put your ELF loader (and other initialization logic) into it's own page-aligned section, then release those pages once your OS is initialized.

Synon wrote:How do you plan to execute modules if your kernel doesn't natively support any executable formats?

This brings up a question I have but for which I have not yet found an answer in my reading -- and, I'm not there yet in my own work to investigate it personally.

Does GRUB load a module into memory only and then it is up to the kernel (or some other module) to parse it out and break it into it's segments? Or, will GRUB take care of that for you and give you a module that is ready to call directly into and execute? Based on the nature of OS development, I would guess it would be the more difficult option.

At least in multiboot 1, modules are loaded unmodified.

There's not much reason to do otherwise - if you bundle a bunch of drivers which happen to be linked to the same physical address, no loader would be able to load more than one of them - and you still need your whole set of drivers.

You're asking whether you need a loader inside your kernel.

Given there is an A loader, and you're asking whether this should be part of your kernel. If we assume it to become a module, something needs to load that module, call it a B loader. Given that you then have a B loader, why do you still need the A loader?

In short, pick one format and build that into your kernel. You need one to not be a module, so that you can load modules. If you have a format that can load modules, why add support for any others?

Whether that one format is ELF or something else is up to you.

In my design, I have the ELF parser and dynamic linker integrated in my kernel, but the loader will be in user space.
One of the reasons why this works for me, is that I don't support modules at any other time than boot time, meaning they're already in-memory by the time the kernel needs them.

I too spent long pondering this question.

My solution was for the "executable reader" to be separate.