Loading the HAL as a module?

[sofferjacob]

So I am writing a kernel (trying to follow an Hybrid Kernel design) and I am trying to place all the code that is architecture dependent on a HAL so porting the kernel will be easier down the road. I want to compile the HAL as a module and then load it when the kernel is booted, so I realized I could do the following:
1) Write an ELF module loader.
2) Write the HAL.
3) Compile the HAL as an ELF module and save it to an initrd.
4) At boot time load the initrd, and from there load the HAL (depending on which architecture is being used).
But the way I thought I would implement the initrd requires loading all the files of the ramdisk into memory, but this is not possible since my memory manager resides in the HAL (and also in order to load ELF modules, you need to load them into memory). So how can I implement this idea or is it impossible to do?
And by the way, is it better to include all HAL related functions (ex. paging functions) in a single header file (hal.h) or to place them in different header files?

I am using GRUB as my bootloader.

Thanks

[eryjus]

I am using GRUB as my bootloader.

Grub can load it for you and tell you where it resides.

[Rusky]

This feels like a case of the tail wagging the dog. The architecture and platform-specific stuff is the lowest level and generally required before any of the more platform-agnostic stuff. You'll run into this in more situations than just the memory manager.

What I'd do instead is reimplement the entry point for each platform, make it part of the HAL, and put it in charge of loading the rest of the kernel.

[dchapiesky]

last time I checked an ELF loader needs certain architecture specific information to actually do it's job...

tail wagging the dog indeed

[zaval]

Here is how I am going to do similar task.
I have two PE images - one for kernel, ant.exe and second for HAL - hal.dll.
The bootloader reads the files from FS and loads them into RAM (as images). Both files have their Base Addresses they have been linked to. And they have dependencies between each other through import/export structures.
Bootloader binds them together (initializes IAT of both) and then jumps into EntryPoint of the kernel. Kernel then calls Hal functions.
Bootloader should be a little a memory manager, file system and PE loader. Get slightly more real. It's impractical and not benefitial to idealize things to the point of "everything machine specific goes to HAL". Most should, not everything. Memory manager is huge, it should be a logically standalone kernel unit. Otherwise your Hal just turns into a big monolithic mess. Hal it's an enumerator of non-enumerable devices. On my mips board (without PCIe) it's almost all controllers.

[Korona]

IMHO the concept of a HAL that sits between kernel subsystems and the hardware is intrinsically broken. Different architectures require different layers of abstraction. See this thread (specifically the replies from Brendan and me) for reasons why this is not possible.

Basically in order to achieve acceptable performance the arch specific code has to hook into other subsystems. It can do this via well-defined interfaces (i.e. in a "portable" manner) but it's still not possible to abstract all required functionality into an independent HAL subsystem.