A Fork in the Road for my OS

[JohnnyTheDon]

With the successful completion of my virtual memory manager, multiprocessor management, interrupt and IRQ system, and the other core parts of my kernel I have now reached a point where I have two paths to take. I can't decide on one, so I would like to hear some input from those more experienced than I (basically everyone). Keep in mind my OS is a microkernel, so the kernel is just a HAL with scheduling.

1. Design and Implement Process Management (threads, IPC, etc.) First
2. Design and Implement Device Management (ACPI, HAL, etc.) First

Process management seems like it would bring the most immediate gratification, because I would actually be able to run programs, which might be a good idea at some point . On the other hand, device management is going to be quite easy, since I use Intel's ACPICA to make detecting and retrieving information about devices simple.

Any suggestions?

[piranha]

VFS, FS drivers, Loadable programs, portable programs, etc.

Then port something like bash to port.

-JL

[Troy Martin]

Expansion on piranha's list, in order of importance from most to least: VFS, FS drivers, program loading, small shell, portable programs, port more known shell, write some programs, port bash or similar.

Oh, and IMHO, don't port csh, let alone ever use it

[Brendan]

Hi,

For a micro-kernel, I'd start Process Management first, and then implement parts of Device Management (e.g. device detection) as a separate process (some sort of "Device Manager" process, for example).


Cheers,

Brendan

[JohnnyTheDon]

That may be a good way to do it for a monolithic kernel, but in a microkernel the kernel typically doesn't know what an FS is or that one exists. I was asking for one of the two choices I have laid out in the OP. BOTH of these are required before a driver can run, let alone a VFS and a shell.

EDIT: Thank you Brendan, hadn't thought of running it as a process.

[Troy Martin]

Well, in that case, option #2. Drivers are needed more than the process management.

[clange]

Start with process management. Then implement drivers as processes. The process images can be obtained from RAM (GRUB modules).

I'm implementing a micro kernel (like) OS too. I have an init process handling loading of drivers etc after the kernel starts. I have a VFS process that handles drivers and file systems. It provides a name space and dispatches system calls to the individual device or file system drivers.

Hope this helps

clange

[JohnnyTheDon]

Thanks, it looks like process management is the way to go.

[Love4Boobies]

Keep in mind my OS is a microkernel, so the kernel is just a HAL with scheduling.

It's a bit odd that you'd implement a HAL for a microkernel. Microkernels are inherently unportable.

[JohnnyTheDon]

Actually, I've decided to move the HAL to userspace. But why would it be inherently unportable?

[Love4Boobies]

Because it prevents you from getting the flexibility and performance you want. Reasons include the inability to take advantage of certain hardware abilities (not every piece of hardware of the same type also has the same features - take rings for example, but it doesn't stop here), nor can it take any precautions in avoiding certain performance issues. Not to say that the HAL itself is another expensive layer (it doesn't matter in a monolithic kernel because those perform well enough). However, I would like to note that they make the rest of the system highly portable, as opposed to (more) monolithic kernels.

[JohnnyTheDon]

HAL is kind of a misnomer (I just didn't know what else to call it). My HAL just enumerates the devices in the system and the resources each take up (using ACPI or the like). It and the kernel will be platform specific, but by using stuff like system call macros I should be able to make the servers cross-platform as well as some of the drivers.

[Love4Boobies]

Well, that is part of the HAL's job, I guess. You can get a better idea of what a HAL (Hardware Abstraction Layer) is when your mind wraps around the word "Abstraction". It's mean to present data collected from hardware to the kernel the way the kernel expects it, not the way the hardware dumps it (e.g. you may be getting your CPUs from either MP tables or ACPI, depending on what the system supports). Drivers are a nice abstraction in this sense too, and if you have some sort of driver interface (like UDI or EDI), that blends in perfectly with the HAL - or might even be part of it.

Also, the HAL can do stuff for you, just like when using drivers. Your kernel doesn't need to know how to do everything, it just tells the HAL when it reaches a more platform-specific point (which is rewritten for each platform). An example of this is ((x2)A)PIC support.

[JohnnyTheDon]

Yeah it isn't really a HAL at all. I guess HIL (Hardware Information Layer) would be a more apt title.

[Colonel Kernel]

Microkernels are inherently unportable.

No they're not. QNX Neutrino and Mach have both been ported to different architectures. Some microkernels are inherently unportable by design (L4), but this is not by virtue of being a microkernel.