6 ms·

Isn't the BIOS supposed to be the hardware abstracting layer we run our programs directly on? That doesn't work any more (because BIOS is a legacy mess), so now

Isn't the BIOS supposed to be the hardware abstracting layer we run our programs directly on? That doesn't work any more (because BIOS is a legacy mess), so now we have kernels that act as the hardware abstraction, and write operating systems on top of those. Of course, now you need to target you operating system to a kernel.

derefr 13y ago
Yes, the BIOS is exactly what's supposed to be doing the hardware abstraction, such that jobs like "read a block from a block device" are done via hardware interrupts, not system calls. I think hypercalls are a good compromise, these days; what is a hypervisor but a BIOS running on the CPU? There are already specialty OSes that take this tack--things like Openmirage (http://www.openmirage.org/ http://www.openmirage.org/) and Erlang on Xen (http://erlangonxen.org/ http://erlangonxen.org/). It could be done with a general-purpose OS just as easily.
- derleth 13y ago
  > what is a hypervisor but a BIOS running on the CPU? Generally, a hypervisor implies a VM which multiplexes the hardware and allows multiple OSes to run at once, which is more than any BIOS has ever done. Also, a hypervisor generally doesn't provide any hardware abstraction, to be compatible with existing OSes which expect to be alone on the hardware.
  - rjsw 13y ago
    If the hypervisor is a paravirtualized one then it will provide hardware abstractions. The Openmirage project described above is essentially an OCaml Machine, it only needs drivers to talk to the generic Xen devices for disk, network, console etc...
- shin_lao 13y ago
  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.
- anttiok 13y ago
  It's already been done with a general purpose OS, see https://github.com/anttikantee/rumpuser-xen/ https://github.com/anttikantee/rumpuser-xen/ I agree, it was easy to do.
derleth 13y ago
> Isn't the BIOS supposed to be the hardware abstracting layer we run our programs directly on? Yes. The problem with this idea is that the BIOS fell prey to a classic negative feedback loop: It wasn't extremely efficient to begin with, and in 16-bit x86 programs can bypass it entirely and go directly to the hardware, so they did. This meant hardware interfaces became more standardized (to a point), to make specific pieces of hardware more attractive to buyers who wanted to run the widest possible variety of application software, and the BIOS was relatively neglected. This cycle continued until the BIOS had essentially code-rotted into unusability, being able to boot Windows and not much else. The final nail in the coffin was when 32-bit x86 chips came out and the BIOS remained 16-bit real mode: Even though protected mode could have saved the BIOS, by making it impossible for application software to go directly to the hardware, the fact the BIOS never jumped to 32-bit code meant not even OSes can really use it. So now the BIOS can run a POST and load a bootloader that actually knows how to load a modern OS. That's pretty much it.
- rbanffy 13y ago
  > It wasn't extremely efficient to begin with Actually, it was quite ridiculous. Printing text to the screen on a 4.77 IBM PC felt like using a serial terminal at about 19200 bps. My 1 MHz Apple II would appear much faster just because it could output text to the screen more efficiently (to be fair, putting a symbol on a CGA screen is a two-byte affair - one for the symbol, one for attributes, but, still, for a supposedly much more advanced machine, it was horrible).
  - derleth 13y ago
    > to be fair, putting a symbol on a CGA screen is a two-byte affair - one for the symbol, one for attributes Text-heavy stuff was supposed to be done using MDA graphics cards, which were praised at their introduction for allowing large amounts of readable text, especially on IBM's own monitors. I'm sure a lot of business users running 3270 terminal emulators and word processors got a lot of good use out of MDA, but the fact it was, as its name stated, monochrome pretty much killed it in the home market. Anyway, the IBM PC was very definitely built to a price point and a release date; it was also built to avoid cannibalizing any of IBM's pre-existing product line, which explains why Compaq, not IBM, would come out with the first PC built around the 80386. It was fairly impressive compared to S-100 bus computers running CP/M but the Apple II crowd would have been forgiven for not being bowled over.

derefr 13y ago

Yes, the BIOS is exactly what's supposed to be doing the hardware abstraction, such that jobs like "read a block from a block device" are done via hardware interrupts, not system calls. I think hypercalls are a good compromise, these days; what is a hypervisor but a BIOS running on the CPU? There are already specialty OSes that take this tack--things like Openmirage (http://www.openmirage.org/ http://www.openmirage.org/) and Erlang on Xen (http://erlangonxen.org/ http://erlangonxen.org/). It could be done with a general-purpose OS just as easily.

derleth 13y ago
> what is a hypervisor but a BIOS running on the CPU? Generally, a hypervisor implies a VM which multiplexes the hardware and allows multiple OSes to run at once, which is more than any BIOS has ever done. Also, a hypervisor generally doesn't provide any hardware abstraction, to be compatible with existing OSes which expect to be alone on the hardware.
- rjsw 13y ago
  If the hypervisor is a paravirtualized one then it will provide hardware abstractions. The Openmirage project described above is essentially an OCaml Machine, it only needs drivers to talk to the generic Xen devices for disk, network, console etc...
shin_lao 13y ago
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.
anttiok 13y ago
It's already been done with a general purpose OS, see https://github.com/anttikantee/rumpuser-xen/ https://github.com/anttikantee/rumpuser-xen/ I agree, it was easy to do.

derleth 13y ago

> Isn't the BIOS supposed to be the hardware abstracting layer we run our programs directly on? Yes. The problem with this idea is that the BIOS fell prey to a classic negative feedback loop: It wasn't extremely efficient to begin with, and in 16-bit x86 programs can bypass it entirely and go directly to the hardware, so they did. This meant hardware interfaces became more standardized (to a point), to make specific pieces of hardware more attractive to buyers who wanted to run the widest possible variety of application software, and the BIOS was relatively neglected. This cycle continued until the BIOS had essentially code-rotted into unusability, being able to boot Windows and not much else. The final nail in the coffin was when 32-bit x86 chips came out and the BIOS remained 16-bit real mode: Even though protected mode could have saved the BIOS, by making it impossible for application software to go directly to the hardware, the fact the BIOS never jumped to 32-bit code meant not even OSes can really use it. So now the BIOS can run a POST and load a bootloader that actually knows how to load a modern OS. That's pretty much it.

rbanffy 13y ago
> It wasn't extremely efficient to begin with Actually, it was quite ridiculous. Printing text to the screen on a 4.77 IBM PC felt like using a serial terminal at about 19200 bps. My 1 MHz Apple II would appear much faster just because it could output text to the screen more efficiently (to be fair, putting a symbol on a CGA screen is a two-byte affair - one for the symbol, one for attributes, but, still, for a supposedly much more advanced machine, it was horrible).
- derleth 13y ago
  > to be fair, putting a symbol on a CGA screen is a two-byte affair - one for the symbol, one for attributes Text-heavy stuff was supposed to be done using MDA graphics cards, which were praised at their introduction for allowing large amounts of readable text, especially on IBM's own monitors. I'm sure a lot of business users running 3270 terminal emulators and word processors got a lot of good use out of MDA, but the fact it was, as its name stated, monochrome pretty much killed it in the home market. Anyway, the IBM PC was very definitely built to a price point and a release date; it was also built to avoid cannibalizing any of IBM's pre-existing product line, which explains why Compaq, not IBM, would come out with the first PC built around the 80386. It was fairly impressive compared to S-100 bus computers running CP/M but the Apple II crowd would have been forgiven for not being bowled over.