OSDev.org

We all know that early OSes used the real mode drivers found in the BIOS and extended them with supplimentary drivers. Here's the real question. How did the drivers in the BIOS know which OS you were gonna load. Were the drivers in the BIOS OS-agnostic or were they tailed for DOS only. Could, say, BSD Unix use those real mode drivers?
Even now that UEFI has 32 or 64 bit drivers, the OS still discards them during the early stages of loading. Why can't it just use them, like in the old-school days.

BIOS (well you might not call that drivers) have well defined interface (but messy implementations...)
There are standard functions for harddisk, display, keyboard, and network booting.

Nowadays these functions are merely used in early boot process for major OSes and thus lack of testing in other circumstance.

BIOS is not meant for performance, it's blocking calls, and it only provide common basic features for the class of device.
Major OSes can afford enough man day for driver development and testing, and they need performance, utilize the device, and a driver that fit the kernel design model, that's why they do not call BIOS.

For UEFI, some of them are designed not callable after the boot process - they simply not designed to serve as driver for OS.

so basically firmware drivers are not as good/performant as native OS drivers. you didn't answer my first question, though.

How did the drivers in the BIOS know which OS you were gonna be used with. Were the drivers in the BIOS OS-agnostic or were they tailored for DOS only?

garegin wrote:How did the drivers in the BIOS know which OS you were gonna be used with. Were the drivers in the BIOS OS-agnostic or were they tailored for DOS only?

1. BIOS don't need to know which OS you going to run. On the other hand, the OS make use of the BIOS which has a well defined interface.
2. No, BIOS is not tailored for DOS, it's tailored according to the specification.

garegin wrote:How did the drivers in the BIOS know which OS you were gonna be used with. Were the drivers in the BIOS OS-agnostic or were they tailored for DOS only?

A bit of both. The original PC had an 8088 CPU, which meant that it could only run in what we now call real mode. Because of back compatibility issues related to that, the BIOS can only run in real mode or Virtual 8086 mode (which emulates real mode in protected mode on 386s and more recent x86 CPUs).

So the BIOS can only be used with OS's that run in real mode or use V86 mode. This doesn't *have* to be DOS, but DOS (including Win9x) is the only major OS I'm aware of that uses real or V86 mode to any extent.

as long long as you followed the spec, any real mode OS could use those drivers? did Unix variants run in real mode?

Hi,

garegin wrote:as long long as you followed the spec, any real mode OS could use those drivers?

Sort of, if the OS is crappy enough to bother.

garegin wrote:did Unix variants run in real mode?

The only one I can think of is Minix 1. Of course (even though Minix 1 was intended for teaching and wasn't intended as a normal OS) I doubt even it was crappy enough to use the BIOS.


You seem to care (even after people have mentioned how bad BIOS is), which I find disturbing. To highlight how bad BIOS is, here's a list of basic features you'd expect from a modern storage device driver:

• It should work all the time. For example, a CD or USB flash driver should work, even if you didn't boot from CD or USB flash.
• Asynchronous IO (software interface). This means that software asks the driver to read/write some sectors, and when the driver has done the work it notifies the software that it has been done (or that it failed for whatever reason). The reason for this is that it allows software (e.g. file system drivers) to do other things (including doing more file IO) while it waits; which is very important in multi-tasking systems (because many tasks might be trying to use the disk at the same time) and also very important in single-tasking systems (where you can't just spawn more tasks to get useful work done while you wait for file IO).
• Asynchronous IO (hardware interface). For all storage devices I can think of, the hardware itself has at least some sort of asynchronous IO capabilities where you send a command, the hardware uses bus mastering or DMA, and you get an IRQ when the command completes. This frees the CPU to do useful work (instead of waiting/polling), which is important for any system that has an asynchronous software interface (especially as disk IO can be extremely slow); but it also means that (for example) the OS can be using several completely different devices at the same time (e.g. reading from USB flash while writing to floppy while transferring data to SATA).
• Prioritised IO interface. If you've got asynchronous IO then you end up with a queue of "pending commands". It makes a lot of sense to do these commands in order of importance. For example, do swap space first and worry about de fragmenting file system/s when there's nothing important read/write.
• Optimised IO. If you've got a queue of "pending commands" then it also makes sense to optimise the order that things are done to improve performance. A typical example of this would be to complete all commands for one track before moving to a different track (as shifting heads is expensive). For example; you wouldn't want to read from cylinder 0, then read from cylinder 999, then read from cylinder 10, then read from cylinder 0 again, then read from cylinder 10 again - you'd reorder these so that the heads are only moved twice instead of bouncing around everywhere.
• Transactions. Sometimes file systems need to make sure something completes before something else is done (e.g. make sure a file's data is actually written to disk before creating a directory entry pointing to the file's data) to ensure that the file system doesn't become corrupted if there's a problem (e.g. a power failure at the wrong time). Once you start doing things out of order (for performance), then you you need something to enforce stronger ordering if/when necessary.
• Support for removable media and hot-plug. If someone ejects a CD, then it'd be nice if the driver told the file system that the disk isn't there anymore. If someone inserts a new CD it'd be nice if the driver told the OS to mount it. If you can support removable media properly, then it doesn't take much to support hot-plug properly too (as it's mostly the same thing). Note that all USB and all SATA is hot-plug (e.g. you should be able to remove a SATA hard drive or add a new SATA hard drive without turning the computer off, and without the OS having a seizure).
• Support for driver loading/unloading. If someone removes the device there's no point having a device driver running anymore - it should be removed (and reloaded/restarted if it's needed again later). This also means that (for example) the OS should be able to update its device drivers without rebooting (e.g. stop/unload the old driver, then load/start the new driver). This sounds complex but if you've got support for removable media and hot-plug devices anyway then it's not hard.
• It should be designed to suit the OS/kernel. This includes things like supporting the OS's executable file format for drivers/modules, and using the OS/kernel's APIs for things like allocating/freeing memory, communicating with other software, etc.

This is just a quick list of "minimal requirements" for storage drivers on any modern OS (it doesn't matter which architecture, or if the kernel is monolithic or not, or what CPU mode the OS uses, or anything else). There's lots of other things an OS could support - whole disk encryption, some sort of "secure erase", some sort of "device health" interface (e.g. see S.M.A.R.T.), virtualisation, etc.

Now; guess how many of these "minimum requirements" the BIOS supports? Not even one.

On a scale from 1 to 10, where 1 means "looks slightly usable from a distance if you squint" and 10 means "adequate", the BIOS isn't even good enough to get a score of 1.


Cheers,

Brendan

To make it worst, the other major half of the BIOS, the keyboard&VGA/VESA (aka console), is about double the worst.

It provide keyboard interface but only support 84 keyboard (as everybody just use the ASCII value I'm not even sure the scan code is correct)
The VGA part is a joke, anyone can do direct access to display memory and do far better job than the BIOS, yet equally "hardware independent" (for standard vga mode that you would ever care - 80x25 text, 640x480x16, and 320x240x256)
and BIOS VESA, you should underwrite an 50% risk of a bug somewhere.

I think Brendan is overly pessimistic. IMO, the major reason why you wouldn't want to use BIOS for a protected mode OS, is that you need to reflect the corresponding hardware interrupts to V86 mode/BIOS. This is both messy and gives poor interrupt latency. I don't think the blocking / busy-polling issue is a real issue. First, there are hooks in the BIOS that are called in busy-polling scenarios. Second, in a multitasking OS, you could easily have one server thread per disc (running in V86 mode) which does the disc requests sequentially. After all, chaos would prevail if anybody could access the disc-hardware, no matter how IO is done. A further problem with USB-discs is that you cannot both have BIOS using the USB chip and the OS, which pretty much rules out letting BIOS handle USB discs if you want to implement other USB functions.

bluemoon wrote:To make it worst, the other major half of the BIOS, the keyboard&VGA/VESA (aka console), is about double the worst.

It provide keyboard interface but only support 84 keyboard (as everybody just use the ASCII value I'm not even sure the scan code is correct)
The VGA part is a joke, anyone can do direct access to display memory and do far better job than the BIOS, yet equally "hardware independent" (for standard vga mode that you would ever care - 80x25 text, 640x480x16, and 320x240x256)
and BIOS VESA, you should underwrite an 50% risk of a bug somewhere.

It's not a joke for setting up video modes. Without this BIOS service, we would need a driver for every graphics card just to setup the mode.

thanks for the thorough responses. to be clear, I fully understand how sucky real mode is. my curiosity was whether they were historical examples of Unixes using the real mode before the debut of the protected mode.

garegin wrote:thanks for the thorough responses. to be clear, I fully understand how sucky real mode is. my curiosity was whether they were historical examples of Unixes using the real mode before the debut of the protected mode.

There were commercial ports of Unix for the 8086 and 80286, using real mode and 16-bit protected mode. They would have most certainly contained both native drivers and BIOS wrappers (..for non-IDE disk I/O, video).

Minix also supported real mode and 16-bit/32-bit protected modes, support for real mode was dropped around 2.x.. I believe the BIOS was used initially, slowly replaced by native drivers, and then eventually deprecated.

At the time, the PC wasn't a really impressive target.. Unix ran on much more capable machines, it wasn't until the i386 that people started taking a closer look again.

rdos wrote:I think Brendan is overly pessimistic. IMO, the major reason why you wouldn't want to use BIOS for a protected mode OS, is that you need to reflect the corresponding hardware interrupts to V86 mode/BIOS. This is both messy and gives poor interrupt latency. I don't think the blocking / busy-polling issue is a real issue. First, there are hooks in the BIOS that are called in busy-polling scenarios. Second, in a multitasking OS, you could easily have one server thread per disc (running in V86 mode) which does the disc requests sequentially. After all, chaos would prevail if anybody could access the disc-hardware, no matter how IO is done. A further problem with USB-discs is that you cannot both have BIOS using the USB chip and the OS, which pretty much rules out letting BIOS handle USB discs if you want to implement other USB functions.

The BIOS assumes it is fully in control of the machine. Emulating this sufficiently to invoke the BIOS from one thread is difficult. Invoking the BIOS from multiple threads is just asking for things to break in unpredictable and weird ways.

Never mind that the BIOS will, at best, use the incredibly slow ISA DMA controllers and more than likely just use PIO, can only read into the bottom 1MB, etc, etc

rdos wrote:It's not a joke for setting up video modes. Without this BIOS service, we would need a driver for every graphics card just to setup the mode.

Wrong. You only need a VGA driver to support them all.

Combuster wrote:

rdos wrote:It's not a joke for setting up video modes. Without this BIOS service, we would need a driver for every graphics card just to setup the mode.

Wrong. You only need a VGA driver to support them all.

I don't find any VGA mode sufficient for graphics. I don't even support bit-plane graphics. Besides, every working VGA driver assumes some way to setup the hardware in the desired mode, and this is typically different between chipsets and implementations. That's what you need BIOS for.