Common HAL
Posted: Fri Nov 29, 2013 4:41 pm
Hi, just something I've been thinking of lately. Would a common Hardware Abstraction Layer be useful? Would it be possible to make it small enough to be integrated with multiple OSes? Would other people support it if the design was simply and easy to support like a protected mode BIOS?
This design is for PCs booted from BIOS but if the API was designed simply enough it may be able to support other systems. It would not use BIOS calls for anything other than Video modes/VESA support using something like libx86emu, never real mode/protected mode switching. The HAL could be loaded in 2 ways, either from the boot loader as a module for the kernel to initialize or it could be loaded from a multiboot boot loader and load the kernel and other modules after initializing itself.
The details can be fine tuned but the general idea would be that the minimal system would occupy 1MB RAM (maybe expandable to 16MB for extra drivers and DMA access) and can be relocated to anywhere in memory. It would be 32 bit code and can work with 32 bit and 64 bit OSes using 32 bit descriptor entries. The very basic system would support disk access, video control, timer and DMA. Some parts of the system could be disabled or replaced by native drivers from the running OS. HAL drivers could be loaded to include control for memory and paging, advanced CPU features, sound, network, etc.
The requirements in an OS to use the HAL would be to create 2 Descriptors (GDT or LDT), 1 for data and 1 for code. The base would be any where the HAL was loaded/relocated and the limit would be 1MB. Any system calls to the HAL would require the data to be within this 1MB space and with paging this data could be shared memory between the HAL and kernel without mem copy. Care needs to be taken when mapping DMA memory.
The interface was designed to be similar to BIOS but without using any BIOS services. To call a service you would set the service in EAX, set any parameters in a buffer within the 1MB area and set the buffer address (0 based) in EDX. The devices number would be based on the old real mode BIOS interrupt numbers and is set in the top half of EAX. The call could be from an interrupt or a far call to the HAL segment.
An few examples follow:
Set the video mode (VESA service support only)
Read the 1st sector from the FDD
The structures may change to be 32 bit aligned but the idea is there to be easy to know how system calls work from most old BIOS interrupts. The main idea behind this is to have a small and simple way to access hardware for simple kernels. The target user is an OS Dev coder that wants to build a working kernel with some basic hardware support without worrying about the device driver interface and writing custom drivers for the base PC system.
This design is for PCs booted from BIOS but if the API was designed simply enough it may be able to support other systems. It would not use BIOS calls for anything other than Video modes/VESA support using something like libx86emu, never real mode/protected mode switching. The HAL could be loaded in 2 ways, either from the boot loader as a module for the kernel to initialize or it could be loaded from a multiboot boot loader and load the kernel and other modules after initializing itself.
The details can be fine tuned but the general idea would be that the minimal system would occupy 1MB RAM (maybe expandable to 16MB for extra drivers and DMA access) and can be relocated to anywhere in memory. It would be 32 bit code and can work with 32 bit and 64 bit OSes using 32 bit descriptor entries. The very basic system would support disk access, video control, timer and DMA. Some parts of the system could be disabled or replaced by native drivers from the running OS. HAL drivers could be loaded to include control for memory and paging, advanced CPU features, sound, network, etc.
The requirements in an OS to use the HAL would be to create 2 Descriptors (GDT or LDT), 1 for data and 1 for code. The base would be any where the HAL was loaded/relocated and the limit would be 1MB. Any system calls to the HAL would require the data to be within this 1MB space and with paging this data could be shared memory between the HAL and kernel without mem copy. Care needs to be taken when mapping DMA memory.
The interface was designed to be similar to BIOS but without using any BIOS services. To call a service you would set the service in EAX, set any parameters in a buffer within the 1MB area and set the buffer address (0 based) in EDX. The devices number would be based on the old real mode BIOS interrupt numbers and is set in the top half of EAX. The call could be from an interrupt or a far call to the HAL segment.
An few examples follow:
Set the video mode (VESA service support only)
Code: Select all
mov eax, 0x00104f00
mov edx, data
mov [data], videomode ; AL register
mov [data + 1], videomode_data ; BX register
int XX
Code: Select all
mov eax, 0x00130200
mov edx, data
mov [data], 01 ; AL register
mov [data + 1], buffer ; BX register
mov [data + 3], 0 ; CX register
mov [data + 5], 0 ; DX register
call FP:hal_service