OSDev.org

I'd like to correct some of these misconceptions.

Microkernels do not include the majority of drivers. The kernel proper mainly consists of two parts - the hardware specific layer and the process / IPC layer. The former is device-dependent, the latter is not. That means at least half the kernel is portable.

For the interest of applications, you want a consistent interface. CD drivers shouldn't behave completely different from floppy drives, and file accesses should be consistent as well. That means that there is a HAL, but it resides partially in userspace.

As for porting, there will always be parts that need to be redone for each OS. Proper design will however minimize this amount. The only real difference between a monolithic/modular kernel is that more of the portable code is separated from the kernel itself, allowing for less in the real kernel to be portable. However, all the stuff that makes the OS still work doesn't need the platform-specific stuff, so there's little work to do there anyway.

So while calling a microkernel inherently unportable may be slightly true, its also an insult in the direction of the OS it stands for.

Edit: the Colonel beat me to the point.

Combuster wrote:For the interest of applications, you want a consistent interface. CD drivers shouldn't behave completely different from floppy drives, and file accesses should be consistent as well. That means that there is a HAL, but it resides partially in userspace.

I think the term "HAL" is being mis-used in this thread. What you've just described, a consistent way for apps to use hardware devices, is... the operating system itself! HAL is typically used to refer to the part of the kernel that encapsulates machine-specific details to allow the rest of the kernel to be portable, even just to different machines of the same family (e.g. -- in Windows, there are different HALs for MP and UP... the former uses the APIC while the latter, in older versions anyway, would probably use the PIC instead).

Combuster wrote:Edit: the Colonel beat me to the point.

No need for a long explanation where a simple counter-example will do.

What you've just described, a consistent way for apps to use hardware devices, is... the operating system itself!

My HAL related entity is used by drivers, not user applications. As I said before, calling it a HAL doesn't really work because it just hands drivers configuration information about their device from ACPI or something similar. My idea is something like this:

| User Applications |
| Servers |
| Drivers | HAL |
| Kernel |

Essentially the HAL is just a driver that tells other drivers about their devices. User applications use servers as a consistent way for apps to use hardware devices. In turn, the servers use drivers as a consistent way to use hardware devices, who use the HAL to find their devices. I guess something like Configuration Driver would be the most appropriate name.

They haven't been ported with HALs. It's been done "by hand". And I never said the drivers are part of the microkernel...

Would you ever use a microkernel without drivers?

*shrugs* No, but I can't see your point...

Love4Boobies wrote:They haven't been ported with HALs. It's been done "by hand".

"HAL." You keep using that word. I do not think it means what you think it means.

What do you mean "by hand"? Someone has to do the work of porting, yes, but for an OS to be portable its source code must be structured in some way that it can be built for different architectures from the same code base. Porting "by hand" as you say sounds more like a re-write, which is not what we're talking about here.

QNX does have a HAL, it just doesn't call it a HAL. In the QNX world it's called a Board Support Package (BSP), but it's the same thing as a HAL.

@JohnnyTheDon:
What you're describing would be called a "bus driver" or "enumerator" in the Windows world AFAIK.

I have described earlier what I would expect from a HAL. Don't confuse this with Windows' HAL, which is basically a motherboard driver. It's just a matter of how much HAL you're willing to put in the HAL, I guess.

P.S: Aren't we going a bit OT?

Love4Boobies wrote:I have described earlier what I would expect from a HAL. Don't confuse this with Windows' HAL, which is basically a motherboard driver. It's just a matter of how much HAL you're willing to put in the HAL, I guess.

P.S: Aren't we going a bit OT?

A motherboard driver? AFAIK Windows' HAL is probably one of the best examples of a HAL. IIRC Windows' HAL does things like translation of I/O references from drivers to either MMIO or IO ports depending on the platform and setup. That is a LOT more than a motherboard driver.

AFAIK, it just hides details such as I/O interfaces, MP communication mechanisms, interrupt controllers. Applications and drivers aren't no allowed to handle hardware directly anymore. They have to make use of HAL services. Nothing more, nothing less.

Love4Boobies, wouldn't the act of hiding the details be Hardware Abstraction? I mean, even a driver is a HAL, because it abstracts the details of the device and gives the kernel a standard interface to said device. set_video_mode(MODE_X); would be the same regardless of what graphics card you have, even if the code to set a video mode was completely different from this card to that one. just like setting up your devices would be something like devicelist[] = enum_devices(); whether on an IBM compatible or PowerPC or Mobile phone. I completely agree with the the the others about the description of a HAL.

Also, while I am not sure and I suppose wrong since no one has blown away your statement completely, I would think that a micro kernel would have the best chance at being portable because all you would do is customize the HAL code to match the Hardware your OS would be on and bingo your OS has been ported because the HAL would deliver the same interface to the kernel regardless of system configuration. Now you would have to rewrite your drivers and what not, but the kernel and the way it handles things wouldn't need a single change if properly coded. That is why for my system I want a ram drive loaded before anything else so that I can simply change the files in the RAMDrive and allow my kernel to load whatever is in there with the HAL being loaded first. I can then have the kernel do the system required functions such as loading the gdt, idt, and setting up proper memory management by running a HAL initialization routine. after that, I would need to run any required routines found in the other "driver" files such as Filesystem and process management.

But again anything that hides or "abstracts" the details of a hardware mechanism is a HAL regardless of its end function.

P.S. I do think we have gone off topic and as to the OP I am not sure which way he would go, but I would choose the more rewarding #1 because I have to see something happen every once in a while or I get tired and stop working on things.

AFAIK, it just hides details such as I/O interfaces, MP communication mechanisms, interrupt controllers. Applications and drivers aren't no allowed to handle hardware directly anymore. They have to make use of HAL services. Nothing more, nothing less.

That is what I said as an example of one feature of the Windows HAL. It allows the driver to write to a "resource" that could be either in port I/O space or MMIO space. This does involve a performance hit, which is why some parts of Windows (ie DirectX) bypass it. And drivers are always allowed to handle hardware directly in Windows or any other monolithic system, because they run at ring 0 and any attempt to stop them from doing something can be overridden.

@ LordMage: Don't worry about being technically OT, I did want some input about the HAL and whatnot.

LordMage wrote:Love4Boobies, wouldn't the act of hiding the details be Hardware Abstraction? I mean, even a driver is a HAL, because it abstracts the details of the device and gives the kernel a standard interface to said device.

Exactly my point. Did I say otherwise?

Also, while I am not sure and I suppose wrong since no one has blown away your statement completely, I would think that a micro kernel would have the best chance at being portable because all you would do is customize the HAL code to match the Hardware your OS would be on and bingo your OS has been ported because the HAL would deliver the same interface to the kernel regardless of system configuration. Now you would have to rewrite your drivers and what not, but the kernel and the way it handles things wouldn't need a single change if properly coded. That is why for my system I want a ram drive loaded before anything else so that I can simply change the files in the RAMDrive and allow my kernel to load whatever is in there with the HAL being loaded first. I can then have the kernel do the system required functions such as loading the gdt, idt, and setting up proper memory management by running a HAL initialization routine. after that, I would need to run any required routines found in the other "driver" files such as Filesystem and process management.

I never said you can't code a HAL for a microkernel, but you're not supposed to. You're not taking advantage of it properly (aside from the fact that microkernels are, let's face it, SLOW). My use of the word inherently was from a real-life implementation point of view. What you described there is exactly the purpose of a HAL. To see my point, try thinking of a clever implementation for a microkernel HAL and see what you can come up with.

But again anything that hides or "abstracts" the details of a hardware mechanism is a HAL regardless of its end function.

Please, re-read my posts, I've said all this already.

Love4Boobies wrote:I never said you can't code a HAL for a microkernel, but you're not supposed to. You're not taking advantage of it properly

Not supposed to? Who gets to say that? And why couldn't you take advantage of it properly? Just because drivers are in user space, doesn't mean they can't use a HAL. In fact, if your architecture doesn't support direct I/O from user mode, a HAL would be a great idea because I/O requires a system call anyway.

Love4Boobies wrote:(aside from the fact that microkernels are, let's face it, SLOW).

Not true. From Wikipedia:

Wikipedia wrote:Performance is therefore a potential issue in microkernel systems. Indeed, the experience of first-generation microkernels such as Mach and Chorus showed that systems based on them performed very poorly.[9] However, Jochen Liedtke showed that Mach's performance problems were the result of poor design and implementation, and specifically Mach's excessive cache footprint.[8] Liedtke demonstrated with his own L4 microkernel that through careful design and implementation, and especially by following the minimality principle, IPC costs could be reduced by more than an order of magnitude compared to Mach. L4's IPC performance is still unbeaten across a range of architectures.[10][11][12]

JohnnyTheDon wrote:Not supposed to? Who gets to say that? And why couldn't you take advantage of it properly?

Now that you've mentioned him, even Jochen Liedtke said this. Take a look over his work for a better understanding of this.

Love4Boobies wrote:(aside from the fact that microkernels are, let's face it, SLOW).

Not true. From Wikipedia:

Wikipedia wrote:Performance is therefore a potential issue in microkernel systems. Indeed, the experience of first-generation microkernels such as Mach and Chorus showed that systems based on them performed very poorly.[9] However, Jochen Liedtke showed that Mach's performance problems were the result of poor design and implementation, and specifically Mach's excessive cache footprint.[8] Liedtke demonstrated with his own L4 microkernel that through careful design and implementation, and especially by following the minimality principle, IPC costs could be reduced by more than an order of magnitude compared to Mach. L4's IPC performance is still unbeaten across a range of architectures.[10][11][12]

L4 isn't so great. It uses segmentation (which isn't even available in 64-bit mode) in order to reduce the need for TLB flushes. And even on 32-bit modes you have problems if you're running more processes than you should - check to see how the address space is divided. It probably decreases performance even more. They even say that all their experiements measure the 'best case scenario'. That's not good enough, now is it?

EDIT: Oh, and another thing. One day, when we'll have HUGE caches, if access times don't decrease DRAMATICALLY, microkernels will keep getting slower and slower.