Relation between Kernel & BIOS routines

Question

How does a Kernel provides different functionality to OS? Does it use the BIOS routines or use special device drivers for this, or something else? If uses BIOS how does it come to know which routine performs what because different BIOS vendors have different coding? If not then what's the use for BIOS routines?

Answer 1

I recommend you this website: OSDev Wiki

It is a very fine page that gives you great introductions to the very basics of an operating system as well as a lot of example codes to even write your own OS.

It might be a little-low level but besides the very detailed descriptions there are also some general explanations on this topic. Imho it is a great source if one really wants to understand Operating Systems.

---

Try this:

What is a kernel?

The kernel of an operating system is something you will never see. It basically enables any other programs to execute. It handles events generated by hardware (called interrupts) and software (called system calls), and manages access to resources.

The hardware event handlers (interrupt handlers) will for instance get the number of the key you just pressed, and convert it to the corresponding character stored in a buffer so some program can retrieve it.

The system calls are initiated by user-level programs, for opening files, starting other programs, etc. Each system call handler will have to check whether the arguments passed are valid, then perform the internal operation to complete the request.

Most user programs do not directly issue system calls (except for ASM programs, for instance), but instead use a standard library which does the ugly job of formatting arguments as required by the kernel and generating the system call. (For example, the C function fopen() eventually calls a kernel function that actually opens the file.)

The kernel usually defines a few abstractions like files, processes, sockets, directories, etc. which correspond to an internal state it remembers about last operations, so that a program may issue a session of operation more efficiently.

And maybe in addition read this.

BIOS

BIOS (Basic Input/Output System) was created to offer generalized low-level services to early PC system programmers. The basic aims were: to hide (as much as possible) variations in PC models and hardware from the OS and applications, and to make OS and application development easier (because the BIOS services handled most of the hardware level interface).
...

Answer 2

If not then what's the use for BIOS routines?

To get a kernel running properly you need to load it (and possibly other things - drivers, "init RAM disk", etc) from somewhere (disk, CD, network) into memory. The kernel will also need various pieces of information (e.g. a physical memory map) and may want some pieces of hardware configured a certain way (e.g. video card might be configured early during boot so OS can use video as a generic "frame buffer" when there is no video driver). The BIOS is used for all of these things before the OS is able to do anything itself.

Basically, the BIOS (or something that provides similar functionality - e.g. UEFI) is required very early during boot and then typically discarded after that.

Also note that BIOS functions and UEFI functions are designed for "single CPU, single tasking, (effectively) no paging, synchronous interface"; and most modern OSs are designed for "multi CPU, multi-tasking, with paging, asynchronous interface". This makes the device drivers built into firmware (both BIOS and UEFI) useless for a modern OS after boot.

Answer 3

First, the BIOS (which is specific to PCs; most other computers, notably servers & tablets, have different firmware) is hardly used these days, except to boot the operating system kernel (and also for some weird things like ACPI & SMI), usually through some boot loader like GRUB (but both Windows and MacOSX have their own boot loaders).

32 bits (or 64 bits) operating system kernels like Linux don't really use the BIOS, but have their own drivers.

Please read also the wikipage about BIOS (and also UEFI) and about operating system.

^{I suggest to install, use, and study a free software OS like Linux; you'll be able to study all the relevant source code!}

In the 1980s MS-DOS invoked BIOS services through INT 13H (which is probably still used by most boot loaders today).

See also osdev, it has lots of wikipages related to your question (and some examples of code).

Answer 4

How does a Kernel provides different functionality to OS?

The OS would access kernel functionality via a system call interface.

In the x86 architecture the int instruction takes an interrupt number as an argument which it uses to generate a software interrupt to which an interrupt handler will respond to. The kernel would have its own interrupt number. The kernel knows what to do because there is a calling convention to follow when attempting to utilize a system call.

As an example, to open a file on an x86 Linux machine, one would place the integer 5 in the eax register (the system call number), a pointer to the filename string in register ebx, flags in register ecx, mode in register edx and then call the software interrupt with int $0x80. The kernel then services the system call and returns control back to the program. There are more efficient ways to access kernel services but they are OS specific.

Does it use the BIOS routines or use special device drivers for this, or something else?

Modern kernels would interface with hardware via device drivers.

how does it come to know which routine performs what because different BIOS vendors have different coding?

You interface with the BIOS via interrupts as well, except they would need to take place in "real" mode as opposed to the "protected" mode which CPUs typically operate in. Real mode is a 16 bit mode which gives software unlimited access to all addressable physical memory and peripherals. These are not BIOS specific but CPU architecture specific.

If not then what's the use for BIOS routines?

To be used during the initial boot process mainly.