OSDev.org

rdos wrote:AFAIK, ELF and PE was invented for applications, not for kernels. For applications, it makes sense to keep symbol-tables in the executable image, and to provide relocation information. It is questionable to have this in OS kernels. There is generally no reason to do run-time relocations in an OS kernel, and there is usually no "application" loader involved in loading and managing pagefaults in the OS-kernel.

Oh, I really like the questionable feature of being able to debug my kernel with gdb. And there seem to be some people who like to implement a modular monolithic kernel, they certainly have their uses for a proper binary format. Stack traces with functions names in them are nice, too.

rdos wrote: AFAIK, ELF and PE was invented for applications, not for kernels. For applications, it makes sense to keep symbol-tables in the executable image, and to provide relocation information. It is questionable to have this in OS kernels. There is generally no reason to do run-time relocations in an OS kernel, and there is usually no "application" loader involved in loading and managing pagefaults in the OS-kernel.

IOW, the typical application formats (ELF and PE) does not seem quite adequate for an OS kernel.

I agree most except the word generally and all remaining points.

Furthermore, I don't see any advantage to use different executable format for kernel and application. Unless you need something beyond the capability of ELF/PE.
The symbol-table is not a good reason to not use it, it is optional and you can use ELF with no symbol-table for kernel.

Indeed, for some embedded design it may be desirable to export some functions from main kernel image for linking with modules.

Kevin wrote:Oh, I really like the questionable feature of being able to debug my kernel with gdb. And there seem to be some people who like to implement a modular monolithic kernel, they certainly have their uses for a proper binary format. Stack traces with functions names in them are nice, too.

You don't need symbols in the executable file in order to debug. I generate the symbolic information for kernel/device-drivers in separate symbol files that are not in the OS binary, but rather on the debugger host. That solves the issue without involving the OS image file. And I have a hard time believing that a typical OS kernel will need to be loaded at different physical addresses, and thus needs relocation information.

BTW, my device-drivers can be loaded at any linear address without relocation, but that is because they setup selectors. The kernel OTOH, is always loaded at the same linear address.

I don't want to copy your kernel, thank you very much.

Of course you can work around the lack of a proper binary format. As you said before, with assembly you don't need ELF. (And as you see a relationship between C and ELF, you'll be surprised to learn that I have compiled ELFs from code that wasn't C, including assembly code; and I have compiled C code into formats other than ELF, including flat binaries).

However, it is useful, with assembly or any other language. Because it saves you the time to invent mechanisms to work around problems that you wouldn't have if you had used a proper binary format from the beginning.

I know that ELF / PE is not only C. I have built PE-based DLLs in assembly-only as well.

ELF/PE kernel format is useful to make relocatable kernel and to link kernel with other modules by stage 2 boot loader.

I'm recompiling kernel to change kernel base between 2G/3G. My kernel dinamically links with drivers by self. So no reason to use ELF/PE kernel format for me. Only drivers use relocatable file format.

rdos wrote:BTW, my device-drivers can be loaded at any linear address without relocation, but that is because they setup selectors. The kernel OTOH, is always loaded at the same linear address.

If i remember right, v2os used the same method, which seem to work well.

As a matter of fact, you don't need relocation in a well-designed OS at all. Each application can be loaded to the same offset using virtual memory (I suppose you're using it anyway). Similarly each library can have it's own address (like dll's used to in win xp). Do not forget about position independent code and jump tables either (like Amiga did).
So rdos is correct about this, but for the wrong reasons imho.

I used separete address spaces for drivers (kernel modules, not servers; servers use separate virtual address spaces) before august, 2008. But now I use full flat model because it more simple despite that it required to relocate kernel modules.

berkus wrote:

turdus wrote:As a matter of fact, you don't need relocation in a well-designed OS at all. Each application can be loaded to the same offset using virtual memory (I suppose you're using it anyway). Similarly each library can have it's own address (like dll's used to in win xp).

I'd be happy to hear how'd you do that for a single-address-space OS.

I have already described how to do this. First you use selectors with zero-base to achieve position independent code. Then you define syscalls so it is possible to patch syscall code to real far-calls. This works fine with SMP as well, as I have already shown elsewhere.

berkus wrote:I'd be happy to hear how'd you do that for a single-address-space OS.

You have proven (again) you're not good at reading. I wrote:

turdus wrote:using virtual memory

Which means multiple address spaces, one for each thread.

But, it's still possible to do that for a single-address-space OS, see http://amigadev.elowar.com/read/ADCD_2. ... e0000.html
To save you time, here's the answer on page node0012.html: "Amiga run-time libraries may be positioned anywhere in memory because they are always accessed through a jump table."

berkus wrote:Damn it again! I'm using virtual memory and also using single-address-space. Oh lord, what am I doing wrong?

Maybe nothing. For me the term "single-address-space OS" means only one common address space for everything (kernel, drivers, apps etc.), but I could be wrong too.

Love4Boobies wrote: Nah, even today. We just tell people they're good at it to trick them into avoiding a premature optimization. For the moment, they're very far from beating an experienced assembly programmer.

I would second that; especially if there is a loop with a large number of iterations involved. In assembly language there can be a noticable blip whilst the loop is executing, but the same thing coded in C can leave you thinking that the computer has hung.

However, some user would be satisfied for perspective performance.

Think about this
1. a tightly optimized piece of code & data that runs for one minutes, with no interaction with user (and harder to maintain code).
2. A modular slow code that runs for 5 minutes, but is well break down into mile-stones that can provide visual cue on, say, a progress bar.

For some software, both developer & the user may be more happy with the slow one. We should consider that too when planing to do optimization.
(You may think, doing both 1&2 not exclusive, but then you need to justify the increase in development cost)

Casm wrote:

Love4Boobies wrote: Nah, even today. We just tell people they're good at it to trick them into avoiding a premature optimization. For the moment, they're very far from beating an experienced assembly programmer.

I would second that; especially if there is a loop with a large number of iterations involved. In assembly language there can be a noticable blip whilst the loop is executing, but the same thing coded in C can leave you thinking that the computer has hung.

Got any evidence of that? No? Didn't think so.