5 ms·

The BIOS provides the programmer with basic I/O routines, but let's say performance wise it's far from being very efficient... And access from protected mode is

The BIOS provides the programmer with basic I/O routines, but let's say performance wise it's far from being very efficient... And access from protected mode is quite tricky (but possible if you don't care about performance, security and reliability, but FreeBSD does it routinely to guess supported video modes from the graphic card). When I read you, you seem to believe that writing to a disk (for example), is just a matter of having a "driver". That might be possible in a world where caching doesn't exist and where you don't have to support shitload of devices that claim to be a disk but really aren't or other drivers trying to pretend that they are a disk or other drivers trying to catch your writes to the disk, but really, you don't need an os I guess, just something minimal with hypercalls? Tell me then, just as a thought experiment, if you get a kernel panic, what do you tell to the disk controller? Not today? A snarky comment, I know, but I happen to be a kernel programmer and reading your comment was really annoying.

derefr 13y ago
I'm assuming a full hypervisor, like Xen, which is basically a full-blown kernel that does its own resource pooling and abstraction. A "disk" for Xen is just like a "disk" for Linux--something that presents a disk-like interface in its driver and nothing more. Let me rephrase my previous idea. You have two kernels. One is an exokernel/library kernel, responsible only for managing the hardware[1]. It only does things when it's called into. The other is a "userspace" kernel, that does the virtual memory, process/thread management, etc. It's the one that registers interrupt vectors. You could do this to Linux, today. Rip all the stuff that starts the machine and initializes the devices and abstracts them out, away from all the stuff that touches userspace, and put an known ABI between them. Then, take advantage of modern processors' specific support for hypervisors to make this ABI more performant. The important idea is not that "somebody else" deals with the "drivers and stuff", leaving you free to write "just" an OS. Both the driver part and the process part can be considered part of one OS, and you can't have just one or the other, and likely the same vendor will be worrying about both. No, the important part is that each is a layer, which should be able to treat the other layer as a black box with a known interface. In exactly the same way that TCP doesn't care whether it's being carried by IP or NetBEUI, while IP doesn't care whether it's carrying TCP or UDP, moving the driver part of a kernel out into a hypervisor means that the process-management part doesn't have to care what hardware-management part it's talking to, and vice versa. An "OS stack", to match your "network stack." Really, we already have "OS stacks" in a sense -- that's when we run a full-blown Linux kernel, running an (optionally paravirtualized) IA32/64 emulator, running another full-blown Linux kernel, running your software. This just eliminates everything redundant about that configuration, while keeping all the advantages. --- [1] Notably, this also means that the outer kernel is responsible for permissions to the hardware. This means that each "inner kernel" running on this hardware only gets a single effective permission-set; if the one process on the inner kernel has access to a resource (a disk, say), then every process on the inner kernel has access to that resource, because the inner kernel doesn't deal with the hypercall--it goes directly to the hypervisor. This would have been a terribly big deal 10 years ago. Now? Who runs things as more than one mutually-untrustworthy user within the same virtual machine any more? Today, if you want separate security contexts, you use containerization. Which is to say, you get the hypervisor, not the OS, to enforce resource permissions.
- zanny 13y ago
  On the latter point, you can actually have the two in one kernel paradigm - use coreboot, run a kernel payload, and use containers. The container kernel hooks are essentially the userspace abstractions without the kernel redundancy.
- shin_lao 13y ago
  Windows has got a Hardware Abstraction Layer: http://en.wikipedia.org/wiki/Hardware_abstraction#Microsoft_Windows http://en.wikipedia.org/wiki/Hardware_abstraction#Microsoft_... Until Windows 4, even the graphic part wasn't in the kernel, eventually they had to compromise for performance reasons. I don't know Linux well enough to answer your question about Linux, but I'm pretty sure that concerns are well separated, however they are so fundamental to what the OS does that you can't just rely on some "external library". An Hypervisor doesn't touch any hardware stuff. Basically if you consider kernel mode to run in ring 0 and user mode to run in ring 3, the Hypervisor runs in ring -1 and just deals with privileges to sum up. At to no instance does the hypervisor deal with the hardware such as disks or network cards. That code lies in the ring 0 kernel. All the Hypervisor says is ... "yeah ok, ring -1 kernel, you can play in that sandbox". For example when you run a VM, the VM emulates hardware but the OS running in the VM stills need drivers... Now it's not that easy to separate the OS from the drivers, because each OS has got some ideas about how the cache should work and how disks should be managed and what is actually a NIC. When you write an OS you make your best so that writing a driver can be done to someone else and the code can be reused (e.g. for writing to multiple OS) but you CAN'T expect to use a common framework because well, at some point you will want to do DMA and you don't want to tell your user that their Intel SSD will run at 10 MiB/s.
  - yuhong 13y ago
    Windows 4 != NT4

derefr 13y ago

I'm assuming a full hypervisor, like Xen, which is basically a full-blown kernel that does its own resource pooling and abstraction. A "disk" for Xen is just like a "disk" for Linux--something that presents a disk-like interface in its driver and nothing more. Let me rephrase my previous idea. You have two kernels. One is an exokernel/library kernel, responsible only for managing the hardware[1]. It only does things when it's called into. The other is a "userspace" kernel, that does the virtual memory, process/thread management, etc. It's the one that registers interrupt vectors. You could do this to Linux, today. Rip all the stuff that starts the machine and initializes the devices and abstracts them out, away from all the stuff that touches userspace, and put an known ABI between them. Then, take advantage of modern processors' specific support for hypervisors to make this ABI more performant. The important idea is not that "somebody else" deals with the "drivers and stuff", leaving you free to write "just" an OS. Both the driver part and the process part can be considered part of one OS, and you can't have just one or the other, and likely the same vendor will be worrying about both. No, the important part is that each is a layer, which should be able to treat the other layer as a black box with a known interface. In exactly the same way that TCP doesn't care whether it's being carried by IP or NetBEUI, while IP doesn't care whether it's carrying TCP or UDP, moving the driver part of a kernel out into a hypervisor means that the process-management part doesn't have to care what hardware-management part it's talking to, and vice versa. An "OS stack", to match your "network stack." Really, we already have "OS stacks" in a sense -- that's when we run a full-blown Linux kernel, running an (optionally paravirtualized) IA32/64 emulator, running another full-blown Linux kernel, running your software. This just eliminates everything redundant about that configuration, while keeping all the advantages. --- [1] Notably, this also means that the outer kernel is responsible for permissions to the hardware. This means that each "inner kernel" running on this hardware only gets a single effective permission-set; if the one process on the inner kernel has access to a resource (a disk, say), then every process on the inner kernel has access to that resource, because the inner kernel doesn't deal with the hypercall--it goes directly to the hypervisor. This would have been a terribly big deal 10 years ago. Now? Who runs things as more than one mutually-untrustworthy user within the same virtual machine any more? Today, if you want separate security contexts, you use containerization. Which is to say, you get the hypervisor, not the OS, to enforce resource permissions.

zanny 13y ago
On the latter point, you can actually have the two in one kernel paradigm - use coreboot, run a kernel payload, and use containers. The container kernel hooks are essentially the userspace abstractions without the kernel redundancy.
shin_lao 13y ago
Windows has got a Hardware Abstraction Layer: http://en.wikipedia.org/wiki/Hardware_abstraction#Microsoft_Windows http://en.wikipedia.org/wiki/Hardware_abstraction#Microsoft_... Until Windows 4, even the graphic part wasn't in the kernel, eventually they had to compromise for performance reasons. I don't know Linux well enough to answer your question about Linux, but I'm pretty sure that concerns are well separated, however they are so fundamental to what the OS does that you can't just rely on some "external library". An Hypervisor doesn't touch any hardware stuff. Basically if you consider kernel mode to run in ring 0 and user mode to run in ring 3, the Hypervisor runs in ring -1 and just deals with privileges to sum up. At to no instance does the hypervisor deal with the hardware such as disks or network cards. That code lies in the ring 0 kernel. All the Hypervisor says is ... "yeah ok, ring -1 kernel, you can play in that sandbox". For example when you run a VM, the VM emulates hardware but the OS running in the VM stills need drivers... Now it's not that easy to separate the OS from the drivers, because each OS has got some ideas about how the cache should work and how disks should be managed and what is actually a NIC. When you write an OS you make your best so that writing a driver can be done to someone else and the code can be reused (e.g. for writing to multiple OS) but you CAN'T expect to use a common framework because well, at some point you will want to do DMA and you don't want to tell your user that their Intel SSD will run at 10 MiB/s.
- yuhong 13y ago
  Windows 4 != NT4