Common HAL

Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Common HAL

Post by b.zaar »

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)

Code: Select all

mov  eax, 0x00104f00
mov  edx, data
mov  [data], videomode  ; AL register
mov  [data + 1], videomode_data  ; BX register
int  XX
Read the 1st sector from the FDD

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
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.
"God! Not Unix" - Richard Stallman

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: Common HAL

Post by bluemoon »

b.zaar wrote:Hi, just something I've been thinking of lately. Would a common Hardware Abstraction Layer be useful?
Yes, and there are UDI and other projects that more or less create a uniform abstract layer for devices.
rdos
Member
Member
Posts: 3276
Joined: Wed Oct 01, 2008 1:55 pm

Re: Common HAL

Post by rdos »

No. The HAL concept is not useful. It just creates more complexity and longer paths between users and hardware. In addition to that, it takes away freedom from OS developers in designing their own favorite interfaces.
User avatar
bluemoon
Member
Member
Posts: 1761
Joined: Wed Dec 01, 2010 3:41 am
Location: Hong Kong

Re: Common HAL

Post by bluemoon »

rdos wrote:No. The HAL concept is not useful. It just creates more complexity and longer paths between users and hardware. In addition to that, it takes away freedom from OS developers in designing their own favorite interfaces.
And people call such own favorite interfaces HAL...
You just need abstraction anyway, while not necessary follow other's.
User avatar
gravaera
Member
Member
Posts: 737
Joined: Tue Jun 02, 2009 4:35 pm
Location: Supporting the cause: Use \tabs to indent code. NOT \x20 spaces.

Re: Common HAL

Post by gravaera »

Yo:

A common HAL for something like VBE is an interestingly meaningless effort, because VBE is already an HAL. You could say the same for a large number of other interfaces, so in the end, what you end up calling an "HAL" is really a glue layer between hardware interfaces and specific kernel designs, which cannot be unified under a single blanket HAL specification.

--Peace out,
gravaera
17:56 < sortie> Paging is called paging because you need to draw it on pages in your notebook to succeed at it.
Kevin
Member
Member
Posts: 1071
Joined: Sun Feb 01, 2009 6:11 am
Location: Germany
Contact:

Re: Common HAL

Post by Kevin »

What is your specific kernel design, for which it couldn't possibly work if it works at the same time with the common models?
Developer of tyndur - community OS of Lowlevel (German)
rdos
Member
Member
Posts: 3276
Joined: Wed Oct 01, 2008 1:55 pm

Re: Common HAL

Post by rdos »

I suppose it all depends on what the HAL is. I certainly have generic interfaces for discs, networks, audio, graphics, printers and I have a VFS. This is necessary in order to expose a non-device dependent interface to applications. I also have a few abstracted interfaces for only kernel space: paging (32-bit or PAE) and timers (using whatever hardware is available).

However, I don't want to add another layer just to abstract the hardware. Any driver is free to use whatever IO, memory-mapped or PCI access they like directly without going through a HAL layer.
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Re: Common HAL

Post by b.zaar »

bluemoon wrote:Yes, and there are UDI and other projects that more or less create a uniform abstract layer for devices.
Ok, another idea... I did a quick search and found Project UDI on sourceforge. It seems complete for the API but lacks drivers. I may be wrong but when I browse other OS's source code it seems everyone is still writing their own FDD and HDD drivers. Would any one support an effort to create an open source library of drivers for one of the UDI/CDI/EDI standards?

Maybe make a simple API library that requires a small osdep interface like a portable C library requires. Having a central collection of drivers for the common devices available would encourage support for one of the standards.
"God! Not Unix" - Richard Stallman

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Re: Common HAL

Post by Combuster »

b.zaar wrote:Would any one support an effort to create an open source library of drivers for one of the UDI/CDI/EDI standards?
Working on UDI drivers. In those rare spare moments I have the time to actually go sit at it, that is.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Re: Common HAL

Post by b.zaar »

Would you be willing to share?

Could a small repo on this server be made for easy access?
"God! Not Unix" - Richard Stallman

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed
Kevin
Member
Member
Posts: 1071
Joined: Sun Feb 01, 2009 6:11 am
Location: Germany
Contact:

Re: Common HAL

Post by Kevin »

We keep CDI drivers in the same git repo as the C header files (gitweb), and contributions are very welcome. It's not a whole lot of drivers that we have, but the basics are there (ATA(PI), floppy, file systems, some NIC drivers (including those for the common emulators), a bit of sound).

I have the beginnings of an AHCI driver and an almost usable FAT driver that I haven't worked on for quite a while, but that I could complete, too, if somebody had an interest in using it. Especially the FAT driver is not a real priority without other users because tyndur has its own old, non-CDI one, but I'm willing to switch.

So if you like to help with the drivers, feel free to contact me or the cdi-devel mailing list; and I might actually get back to do some coding myself, too.
Developer of tyndur - community OS of Lowlevel (German)
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Re: Common HAL

Post by b.zaar »

I've just starting looking at FAT and EXT/2 file system. I'd be happy to do some work on these.
"God! Not Unix" - Richard Stallman

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed
Kevin
Member
Member
Posts: 1071
Joined: Sun Feb 01, 2009 6:11 am
Location: Germany
Contact:

Re: Common HAL

Post by Kevin »

ext2 should be fairly complete by now, but you can have a look if anything that you need is still missing. Next step for that driver would be ext3, i.e. journalling, I guess, though I'm not sure if I would go there.

The FAT one did apparently work for some cases, but still needs some work (see my patch from 2010; libfat repository). I think I should clean that up a bit, document it in English and add license headers and stuff, but then that's something that contributing to would make sense.
Developer of tyndur - community OS of Lowlevel (German)
User avatar
thepowersgang
Member
Member
Posts: 734
Joined: Tue Dec 25, 2007 6:03 am
Libera.chat IRC: thePowersGang
Location: Perth, Western Australia
Contact:

Re: Common HAL

Post by thepowersgang »

UDI suffers a little bit from being such a huge standard, but some have been working on drivers.

I've written a basic NE2000 network driver for it (but I've only tested on my environment, so not sure if it actually conforms to the standard)

https://github.com/thepowersgang/acess2 ... net_ne2000 (NE2000 driver)
https://github.com/thepowersgang/acess2 ... /UDI/Tools (UDI Tools)
https://github.com/thepowersgang/acess2 ... rfaces/UDI (UDI Implementation)
Kernel Development, It's the brain surgery of programming.
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc
User avatar
b.zaar
Member
Member
Posts: 294
Joined: Wed May 21, 2008 4:33 am
Location: Mars MTC +6:00
Contact:

Re: Common HAL

Post by b.zaar »

I've started to play with CDI for now. It already has a few drivers available from the tyndur sources and there is also a CDI library. Some of the code is released under the WTF license so it's free to play around with. Maybe the license should be changed to something more like Public Domain or BSD tho...

I'd like to see something become portable that with a simple osdep.c file the library could be dropped into almost any OS. I don't mind which standard it is but I like the idea of CDI at the moment because it seems simple for a small/hobby OS but should be complete enough for full device support.
"God! Not Unix" - Richard Stallman

Website: venom Dev
OS project: venom OS
Hexadecimal Editor: hexed
Post Reply