OSDev.org

• It further separates the kernel and drivers. If common hardware (say, an Ethernet or graphics card) was shared between two different instances of the kernel on different architectures, the driver would simply need recompilation to the new system call format, calling convention format, and instruction set but would not have to change its source, because it does not rely on a particular architecture's I/O protocols.
• It enables better security and compartmentalization, at least from the context of nefarious or malfunctioning drivers. Because the kernel would mediate driver-hardware access, it could vet the driver's request against the role the driver is assigned to perform. The canonical example presented in the previous thread was that of a compromised, keylogging keyboard driver. The driver, upon mounting, would acknowledge itself to the kernel as a keyboard driver (my thoughts, at least initially, are something analogous to PCI BAR class codes). For the keylogger to do anything with the intercepted data, it would have to transmit to the network stack or hard disk interface, and this would be prohibited by the kernel (if implemented correctly!) on the sole fact that those categories of accesses are external to the scope of a keyboard driver.
• Redirection. It enables the kernel to "virtualize" a device - while most obvious for things such as /dev/null and /dev/random, it would also allow for the kernel to symbolically utilize a resource that may altogether not be present on that machine (such as networked drivers or systems like NASes, computing farms, etc.) but present it to the requesting process as though it were physically present and without requiring that the requesting process be cognizant of that device's status.
• It enables better reliability and development-friendliness, for much the same reasons - a kernel system call allows the kernel to have information about what the drivers are doing and what information they are requesting, which is important for driver development, debugging, and reverse-engineering of proprietary drivers (brings this to mind). It also allows the kernel to take action should a driver meet a threshold of illegal accesses (or just a malfunctioning driver), such as forcibly unloading the module entirely or taking other administrative action against it.

Wikipedia wrote:The servers collectively implement the POSIX API, with each server implementing a part of the interface. For instance, the various filesystem servers each implement the filesystem calls.

• "Synchronous". Easier for programmers (requests/replies behave a bit like function calls/returns). Impossible to avoid task switches. Micro-kernel developers using this tend to focus on "extremely fast task switches" because they're impossible to avoid, and tend to favour smaller messages (e.g. messages small enough to fit in CPU registers). This is more suited to single-CPU systems (where a request can't be handled in parallel while sender does something else anyway).
• "Asynchronous". Harder for programmers (requests/replies behave more like events and aren't like function calls/returns at all). Buffers/queues are used to decouple message send/receive from task switching (which adds overhead for buffer/queue management). Micro-kernel developers using this tend to focus on avoiding task switches (and are less concerned with making task switches fast), and tend to favour larger messages (fewer larger messages rather than more smaller messages). This is more suited to multi-CPU systems (where you want to maximise the amount of work done in parallel where possible to make use of available CPUs).

Brendan wrote:Hi,

Most of this (the first half) is makes perfect sense.

For the second half, you're confusing IPC with kernel API. When a driver calls the kernel to make an IO access request, it calls the kernel API (e.g. using something like "sycall" or "int 0x80" or whatever your kernel API uses), and this is not IPC (e.g. sending a message) and does not involve a task switch.

You also might be conflating the concept of IPC with task switches; which would be completely correct for some forms of IPC (e.g. rendezvous messaging) but isn't true of other forms of IPC (e.g. asynchronous messaging).

For example; for my kernels, sending a message causes the message to be moved to the receivers queue and doesn't (directly) cause a task switch; and receiving a message just means moving it from your queue into your address space and doesn't cause a task switch (unless you do "wait for message" and there are none). An application can send 1234 messages, then the scheduler might (or might not) decide to do a task switch to something else (which may or may not be one of the receivers).

For this; the "best case possible" is that the sender and receiver are running on different CPUs; the sender keeps sending request messages while checking for replies (with "check for message" and not with "wait for message") and handling them if they arrive and never blocks; and the receiver fetches requests, handles them and sends replies and never blocks (unless it run out of requests). In this case sender and receiver might transfer 123456 messages between each other, but there are no task switches at all.

Essentially there's 2 main categories for message passing:

• "Synchronous". Easier for programmers (requests/replies behave a bit like function calls/returns). Impossible to avoid task switches. Micro-kernel developers using this tend to focus on "extremely fast task switches" because they're impossible to avoid, and tend to favour smaller messages (e.g. messages small enough to fit in CPU registers). This is more suited to single-CPU systems (where a request can't be handled in parallel while sender does something else anyway).
• "Asynchronous". Harder for programmers (requests/replies behave more like events and aren't like function calls/returns at all). Buffers/queues are used to decouple message send/receive from task switching (which adds overhead for buffer/queue management). Micro-kernel developers using this tend to focus on avoiding task switches (and are less concerned with making task switches fast), and tend to favour larger messages (fewer larger messages rather than more smaller messages). This is more suited to multi-CPU systems (where you want to maximise the amount of work done in parallel where possible to make use of available CPUs).

POSIX is mostly designed for monolithic kernels; and is not designed to minimise the extra overhead of IPC/message passing that micro-kernels have. It's always disappointing when I see the inevitable performance comparisons between "micro-kernel using API designed for monolithic kernel" and "monolithic kernel using API designed for monolithic kernel". Sadly I never see equally fair performance comparisons between "micro-kernel using API designed for micro-kernel" and "monolithic kernel using API designed for micro-kernel".

While micro-kernels do sacrifice some performance for other goals (that, unlike performance, are harder to measure/compare/benchmark); years of researchers and their "let's use POSIX" idiocy has led people to believe the performance sacrifice is far larger than it actually needs to be.


Cheers,

Brendan

physecfed wrote:So, in the case of the API stuff, what are the typical design factors that make POSIX more tailored to monolithic kernels? That is, how would I design an API for users to interface to that makes optimal use of the microkernel environment? Could I do away with user-application system calls entirely and build the API simply on IPC/message passing to the appropriate service?

    // Send "open and start reading" request for each file

    for(fileID = 0 to 10) {
        build_message(OPEN_WITH_READ, fileTable[fileID].fileName, fileID);
        sendMessage(VFS);
    }

    // Main message handling loop

    errors = 0;
    pending = 10;

    do {
        message = getMessage();
        switch(message.type) {
        case OPEN_WITH_READ_REPLY:
        case READ_REPLY:
            fileID = message.fileID;
            if(message.status != OK) {
                fileTable[fileID].status = message.status;
                errors++;
                pending--;
            } else {
                 fileTable[fileID].fileSize = message.fileSize;
                 fileTable[fileID].fileBuffer = realloc(fileTable[fileID].fileBuffer, currentPos+message.readBytes);
                 memcpy( &fileTable[fileID].fileBuffer[currentPos], message.data, message.readBytes);
                 currentPos += message.readBytes;
                 if(currentPos >= fileTable[fileID].fileSize) {
                     build_message(CLOSE, fileID);
                     sendMessage(VFS);
                 } else {
                     // Didn't read entire file so ask to read next part
                     build_message(READ_NEXT, fileID);
                     sendMessage(VFS);
                 }
            }
        case CLOSE_REPLY:
            fileID = message.fileID;
            if(message.status != OK) {
                fileTable[fileID].status = message.status;
                errors++;
            }
            pending--;
        }
    } while(pending > 0);

• 2 task switches (we'll have to wait after sending the "open and read all these files" for a reply to come back)
• 3 messages (one "open and read all these files", one containing all the replies from VFS and one "close all these files")
• 2 kernel API calls (one to send "open and read" and get the message containing the replies; and one to send the "close all the files")

• 20 task switches
• 20 messages
• 10 kernel API calls

Brendan wrote:For the second half, you're confusing IPC with kernel API.

gerryg400 wrote:This is important. It looks like you are drawing a picture of how you think a microkernel should look and then force-fitting your design onto it.

embryo2 wrote: For micro/nano kernels we have more enhanced set of services. And with monolithic kernel it is the easiest way to write a simple application, but in case of a complex and low-level aware application we again have some troubles. In the last case the troubles move from the requirement to write more code to the land of the "not implemented" constraint - we shouldn't expect something that kernel developers forgot to implement. And actually the last type of constraint is most disgusting because it prevents developers from doing something even if they are ready to write a lot of code. That's why I think the monolithic kernels are less popular among application developers, but are the ones which actually used in many popular OSes (because OS developers have more control over the users of OS's services, including application developers).

embryo2 wrote: But how to classify the kernels then? I think the classification can be made along the loosely defined groups of services. First type - no services kernel (zero-kernel). Second type - basic services kernel (memory, process, thread, basic hardware management services). Third type - application friendly (but may be too rigid) kernel with some APIs for doing many things like file or network access, indirect hardware access like playing sounds or viewing movies and so on.

Linux, Windows, Android and many other OSes then belong to the third type. While many OSDever's OSes belong to the second type. And bootloaders like GRUB and UEFI belong to the first type.

1. Organic growth; people just keep adding code to the existing and rarely refactor, thus you get a big blob of code.
2. Performance; People seem to think that monolithic is faster, though I'm not sure how accurate that is these days. I haven't seen any good comparisons of the two.
3. Easiness; At least initially monolithic is probably easier, however I would argue that once it grows it becomes much more difficult to maintain.