OSDev.org

I have been trying to figure out how a VGA text-mode driver would be implemented in a strict microkernel design.

Would the kernel have a specific system call to write directly to memory for drivers, so that it could write to 0xB8000 (or some other location depending on the system)? Wouldn't this defeat the purpose of the microkernel design though? If drivers had direct access to memory (through system calls), then they could easily crash the system if they contained a bug.

Also, for a microkernel design is it ok to have harddisk and other basic drivers compiled directly into the kernel (they will ofcourse be executed in userland as seperate processes)? I can't think of any other way to boot the system fully without linking some of the basic drivers directly into the kernel, but I am hesitant to do this because part of the elegance of the microkernel design is lost. Once you start having to link drivers directly to the kernel you then have to recompile the whole kernel when a small thing is changed in the harddisk driver.

Anyone have any suggestions about how to get around these issues?


Thanks

RE: the bootstrapping problem with HDD drivers etc compiled into the kernel...

I'm not going for a microkernel design as such, but I am trying to keep things compartmentalised. The system I'm implementing at the moment involves a reasonably complex loader built around the GRUB modules ability - I then load disk and filesystem drivers from that early on, then using that to load the rest of the configuration from the disk. I'm not at the point where I can actually test it, but I see no reason for it not to work, assuming I can code for toffee.

Hi,

fox wrote:I have been trying to figure out how a VGA text-mode driver would be implemented in a strict microkernel design.

In a strict microkernel design, the kernel would probably use IPC to access the (user-space) video driver.

This can be a problem for critical error handling though ("kernel panic"), because if the kernel itself has crashed it can't really rely on user-space services. My solution to this is to reserve a page of physical memory to write critical error data into. The kernel's critical error handler would write to this area first, then attempt to use the video service (or network, or file system). If the kernel crashes while trying to use a user-level service then the critical error data should still be present in the special page of RAM when the OS is rebooted (as long as the computer is reset, rather than turned off then on again). In this case boot code should be able to display the critical error information after the reset (i.e. after the system has been restored to a stable state).

fox wrote:Would the kernel have a specific system call to write directly to memory for drivers, so that it could write to 0xB8000 (or some other location depending on the system)? Wouldn't this defeat the purpose of the microkernel design though? If drivers had direct access to memory (through system calls), then they could easily crash the system if they contained a bug.

Device drivers would only be given access to specific areas of the physical address space (usually only regions used by their device for memory mapped I/O), and normally this would be done by mapping the region into the device driver's address space, rather than using a system call each time the region needs to be accessed.

fox wrote:I can't think of any other way to boot the system fully without linking some of the basic drivers directly into the kernel, but I am hesitant to do this because part of the elegance of the microkernel design is lost. Once you start having to link drivers directly to the kernel you then have to recompile the whole kernel when a small thing is changed in the harddisk driver.

The way I do it is to have a boot image that contains all files needed by the OS (the kernel, device drivers, etc). A boot loader loads the boot image into RAM, and after that everything that is needed is already in memory (or at least enough to get the kernel, the network and filesystems working).


Cheers,

Brendan

Brendan wrote: Device drivers would only be given access to specific areas of the physical address space (usually only regions used by their device for memory mapped I/O), and normally this would be done by mapping the region into the device driver's address space, rather than using a system call each time the region needs to be accessed.

Wouldn't this conflict with security? I'm very confused how user mode drivers are implemented all together. To me, if physical memory is mapped in user space and if no system call is needed tells me theres some security issues there. If this is mapped in kernel space then it seems fine which requires a ring 0 switch to make some form of linear or I/O address space checks.

Thanks for your responses everyone. I wasn't even aware of GRUB or other bootloaders had the ability to load modules.

Wouldn't this conflict with security? I'm very confused how user mode drivers are implemented all together. To me, if physical memory is mapped in user space and if no system call is needed tells me theres some security issues there.

From my understanding Brendan meant that no system call would be needed to read/write physical memory. A system call would still be needed to map that memory to the drivers address space though. So if a driver didn't have the correct permissions to map physical address spaces the kernel could refuse.