ISR's and the HAL

[mark3094]

Hi,

I'm wondering what the general practice is with ISR's and HAL's.
I find the HAL good to keep hardware specific code separate from the Kernel. I am trying to decide whether ISR's should be kept separate to the Kernel or not.

As the first 32 ISR's are system specific, I thought maybe they should go in the HAL, and the rest of the routines can go in the Kernel.

Does this sound alright? What is the best practice?

[qw]

Well, for example task scheduling is something that should go into the kernel, and needs the timer interrupt, but interrupts and ISR's are machine specific. You could place a stub in the HAL that calls the ISR in the kernel. The stub is machine specific, the ISR could be written in portable C.

[turdus]

Hi,

I'm wondering what the general practice is with ISR's and HAL's.
I find the HAL good to keep hardware specific code separate from the Kernel. I am trying to decide whether ISR's should be kept separate to the Kernel or not.

As the first 32 ISR's are system specific, I thought maybe they should go in the HAL, and the rest of the routines can go in the Kernel.

Does this sound alright? What is the best practice?

You are wrong, not only the first 32 ISRs are system specific. Think about IRQs, you always have to send and EOI, which is quite hardware dependent (even only x86 has two different ways for this, PIC and APIC).

I suggest to use what minix does:
- put the ISRs in HAL, but do not do much, just create a message and send it to the appropriate task
- the task knows nothing about interrupts or IRQs, it just accepts a normal message (usually called wait_for_work() or get_work() or something similar) and do what the message ask for.

This approach has several benefits:
- your kernel would be cleaner and easier to port.
- ISRs would be fast, so the possibility to raise an interrupt while you are in ISR is extremely small
- if you handle messages in queue (most likely) no interrupts would be lost
- your device drivers would be interrupt implementation independent, and could use userspace threads (so a bug in a driver won't crash your system like in linux)

Although it has a disadvantage too, there's a latency after receiving and interrupt and starting the handler, but it does not bother the overall system too much, minix runs nice and smooth.

[Casm]

Hi,

I'm wondering what the general practice is with ISR's and HAL's.
I find the HAL good to keep hardware specific code separate from the Kernel. I am trying to decide whether ISR's should be kept separate to the Kernel or not.

As the first 32 ISR's are system specific, I thought maybe they should go in the HAL, and the rest of the routines can go in the Kernel.

Does this sound alright? What is the best practice?

It would be difficult to think of anything more hardware specific than a hardware interrupt, but it all depends how you structure your operating system. For example, you might have a HAL, the device drivers and the kernel as separate modules, or you might merge the HAL into the drivers, or the drivers into the kernel.

The kernal will obviously need a handle on at least the timer interrupt. So you could either have that in the kernel, or call a kernel procedure from the clock driver, or from the HAL.

[gravaera]

Hi:

Hi,

I'm wondering what the general practice is with ISR's and HAL's.
I find the HAL good to keep hardware specific code separate from the Kernel. I am trying to decide whether ISR's should be kept separate to the Kernel or not.

As the first 32 ISR's are system specific, I thought maybe they should go in the HAL, and the rest of the routines can go in the Kernel.

Does this sound alright? What is the best practice?

See, "the HAL" is a very broad term since a kernel is pretty much an abstraction layer to allow the user to exploit his hardware anyway: everything from the scheduler (managing CPU time and creating abstractions to allow the user to control processes, etc), memory manager, driver subsystem, timer subsystem, etc, etc are functions of a kernel, and all of those are abstractions of some feature of hardware.

So let's discard the term "HAL" and be more specific. You have Interrupt management in some subsystem or other, and then you have the driver management subsystem as a related, but logically separate entity. And there we now have the answer: the kernel must handle both of these functional subsystems; Interrupts usually need quick servicing so the interrupt management in most kernels is done in the kernel; The driver management is the layer that initializes drivers and transfers the information from IRQs to the relevant drivers.

So "keeping hardware specific code out of the kernel" is not about keeping IRQ management out of the kernel: it's about keeping driver code out of the kernel, so what you probably inadvertently want is a sort of microkernel type of thing in some way or another; The drivers contain your hardware specific code, so however you handle them is what influences how separated your kernel and your hardware related code modules are.

--All the best
gravaera

[Casm]

So "keeping hardware specific code out of the kernel" is not about keeping IRQ management out of the kernel: it's about keeping driver code out of the kernel, so what you probably inadvertently want is a sort of microkernel type of thing in some way or another; The drivers contain your hardware specific code, so however you handle them is what influences how separated your kernel and your hardware related code modules are.

--All the best
gravaera

My understanding of the HAL is that it is something comparable to the real mode BIOS, except that it goes further and tries to provide a standard interface to things like the interrupt controller. Then the device drivers are built on top of that. That way an operating system can be moved to a new architecture with relatively little code having to be rewritten.

[gravaera]

Hi:

My understanding of the HAL is that it is something comparable to the real mode BIOS, except that it goes further and tries to provide a standard interface to things like the interrupt controller. Then the device drivers are built on top of that. That way an operating system can be moved to a new architecture with relatively little code having to be rewritten.

Depends on how you look at it:

To take your proposed example, interrupt controller management (which is a layer which lies beneath IRQ management, and which the IRQ management layer calls upon when it's managing IRQs): The IRQ managament code would call upon the IRQ controller code which would then delve deep within its many layers of hardware abstraction and wave its wand, fulfil the kernel's request, then return to the kernel reporting that all's well that ends well. Then you may also have other early chipset specific features which need to be called upon before the driver subsystem is initialized, such as watchdog device petting, and timer functionality, and firmware interface specifics, like communicating with the firmware on a board if it uses a standard firmware interface like EFI, or OpenFirmware, etc.

Now all of these are good candidates to place into an "HAL" all tied together, and in an ugly way, providing the required functions when the kernel dips its hand into that black box known as its "HAL".

Another approach would be to recognize that all code in a kernel can be categorized as one of three things: (1) Processor architecture specific code, (2) Chipset specific code, or (3) firmware interaction specific code. So IRQ controller, timer device, etc code would be code in a subfolder of "IBM-PC" or "MAC-2"; For chipsets that use Open firmware, you would have your common code written that would portably (as much as you can) provide OFW on all chipsets, then have per-chipset call-ins to augment the chipset-specific stuff for OFW boards with eccentricities, etc.

As you begin to realize this, you begin to see that a messy "HAL" as a single entity would be more portable as properly isolated chipset-specific, arch-specific, and firmware interface specific code; For things like ACPI, you can implement a simple "kernel libacpi" in its own folder under a "kernel-libs/" subfolder. Suddenly porting to new platforms gets easier since you don't have to re-write a messy "HAL" per platform, but create a new folder for the new chipset, or architecture, and write code only for what is actually new, and move on

--All the best
gravaera