| Unix Content | Register | FAQ | Calendar | Search | Today's Posts | Mark Forums Read |
|
#1
|
| I'm slowly learning how Minix works. My first thoughts were that the microkernel business was about putting drivers in userspace and nothing more. "Because the file system, the process manager and all that stuff really have to go in to the 'classical' kernel, as they need close integration between them", I thought. My astonishment came when I heard that Minix put the filesystem and even *the process manager* in userspace! The weirdness seemed even greater when I heard that Minix indeed put some low lever drivers in kernel land. Clearly, these two astonishments only showed that I was not prepared to understand microkernels yet. Now, I've just read a text about the Minix kernel API [1], and suddently released that all those "kernel calls" aren't really served in the call chain directly. In other words, although they are served by code that runs in kernel mode, they are not executed as classical system calls are. The only System Calls in the classical sense (that is, seved directly in the requestor's call chain, possibly having been called by "traps") that Minix has are the send/receive/sendrec/etc/etc, which are neither POSIX calls nor Unix based calls in any sense. They only serve to support the "real", "app visible" APIs, which are supposed to be implemented in userspace. Then, the final answer to the question about putting the basic subsystems (FS and PM) in userspace is that, in reality, the POSIX APIs are converted to Minix messages in user libraries and sent to the respective processes. Those processes in turn have copies of the kernel datastructures that concern themselves and update those data structures in their own address spaces. Meanwhile, they (the system servers) negotiate among them all the work that usually has to be done to perform the requested call (exactly in the same way as a monolithic one would do, but sending messages instead of calling the functions directly). Finally, the involved servers send messages to the "system" process, which makes the changes efective [2]. This seemed weird at first (and I guess Linus Torvalds thought the same 12 years ago), but now (some minutes after releasing this), I think I'm beginning to like the design. After all, that's what Minix is all about: design. The idea is not really being exceptionally fast, but instead being reliable by using a singular design. Now, putting PM and FS in the kernel seems a really bad idea for a microkernel! Specially with a reasonably elegant alternative. [1] http://www.minix3.org/doc/kernel-api.ps [2] Another point that I didn't release immediately was that the API of the system task is not the POSIX API at all, although some of the calls (aka message types) have similar names. -- João Jerónimo "Computer are composed of software, hardware, and other stuff terminated in "ware", like firmware, tupperware, (...)" - by JJ. |