OSDev.org

Currently, my OS boot from floppy. Since floppy driver is obsolete, i am planning to change the booting media.

As I try to figure out what booting media to use, I realize that no matter what I choose, I need to write device driver for it. Though the Real Mode BIOS may provide me with some interrupts to interact with that device, I am on my own once entered the Protected Mode. So I start to read the < Linux Device Driver 3rd edition > for some guide. But that book is about writing device driver for Linux system. So, that implies that device drivers are specific to operating system.

Now I got the following questions:

- In what aspects does a device driver depend on the operating system?
- How are the operating system and device drivers laid out in memory?
- How do the operating system and device drivers interact with each other?
- If I hot-plug in a device, how does the operating system know where to find the proper device driver?

berkus wrote:Short answer:
- it depends on the OS and its driver model
- it depends on the OS and its driver model
- it depends on the OS and its driver model
- it depends on the OS and its driver model

Longer answer depends on how much your OS is different from Linux. Typically driver uses some memory allocation/memory mapping facilities plus spinlocks and other synchronization primitives. It can range from using everything kernel provides, from kmalloc() to serial I/O for debugging, and to device driver writers implementing everything themselves (happens with proprietary drivers in linux).

Thanks for your reply. So if I want to avoid writing device drivers (because I think they are less related to my interest in OS), and utilize existing Linux drivers for hard disk, cd-rom, and possibly usb, what pre-required facilities do I have to implement?


Also, I am wondering how does an operating syAstem deal with, say hard disk, at the very early stage of the booting? I think no hard disk driver or so is loaded yet at that time. By what means does the operating system interact with devices then?

You would have to write a Linux API emulator (Harder than writing most drivers). You would then have to rewrite it every 2 months when they overhaul their API.

Linux is not a good target for this sort of thing. Also, many Linux driver interfaces are poorly thought out.

smwikipedia wrote:Also, I am wondering how does an operating syAstem deal with, say hard disk, at the very early stage of the booting? I think no hard disk driver or so is loaded yet at that time. By what means does the operating system interact with devices then?

If you are using a bootloader (like GRUB), you can have it load some device drivers as modules into RAM along with your kernel. Then you only need to find and initialize them, and once they are running, you can access the hard drive and load the remaining drivers. Alternatively, your bootloader can load a ramdisk for you, and you only need to implement a ramdisk driver in your kernel and load the remaining drivers from that ramdisk. This is how Linux loads the early boot drivers.

Thanks for your replies. I will update this thread tomorrow.

berkus wrote:initramdisk is what initially contains the necessary drivers, and as the name says, it is some sort of virtual disk device loaded into RAM for you by the bootloader.

GRUB supports loading arbitrary number of modules in various formats and then providing your kernel with information where to find them. LILO can load linux kernel initramdisk and pass it to the kernel. U-boot specification supports putting all supplementary data into a single file which can then be loaded and booted with all this information available to the kernel during startup.

On many embedded and laptop systems essential hardware never changes, so it makes sense to create very minimalistic ramdisks with support for only available hardware. On desktop systems some essential hardware may change, so ramdisks usually include much wider range of drivers to allow booting in exotic configurations.

So, if I understand it correctly, the ramdisk should be nothing but a binary file which contains necessary functions to interact with a certain number of devices. This file should be loaded into memory by my boot loader. And then my boot loader or kernel could call the methods within the ramdisk to interact with supported devices.

If the above is right, I only need to make sure my boot loader or kernel knows where the necessary method entry points are. Is this the purpose of "ramdisk driver"?

A ramdisk is nothing but a "disk" image in memory, which means it normally includes a form of indexing like a filesystem would. It is therefore not simply code available for use. It's just a bunch of files put in a place that is present on all computers, and for which you hardly need a driver to read from - in all other aspects its just like a harddisk and you'll still need all the code you would normally need to access filesystems and to load and execute applications/drivers.

A really smart ramdisk implementation is Linux' initramfs. It works as follows:

• Kernel creates a tmpfs file system and mounts as /. tmpfs is a file system which stores files in memory by locking them into the file system cache.
• initramfs then extracts the CPIO archive onto the tmpfs file system

When you unmount the tmpfs, the data stored within that isn't presently being referenced is thrown away.

After reading the above 2 posts, I am wondering:

Why not just directly load a file into memory? Why do we need to use extra steps to store the file in the ram disk and then load and parse the ram disk to get the file?

What's the whole point of ram disk?
What makes us have to use a ram disk?

Hi,

smwikipedia wrote:Why not just directly load a file into memory? Why do we need to use extra steps to store the file in the ram disk and then load and parse the ram disk to get the file?

What's the whole point of ram disk?
What makes us have to use a ram disk?

Think of it as 3 steps:

1. Boot code uses firmware to load some stuff into memory
2. OS takes control of the computer, which makes the firmware unusable
3. OS loads more files from disk

Things like device drivers, file systems, etc that the OS needs for "step 3" must be loaded during "step 1"; otherwise the OS won't be able to load anything after boot. This isn't too hard for a monolithic kernel (if drivers, file systems, etc are built directly into the kernel), but for other types of kernels (e.g. micro-kernels and for modern/modular monolithic kernels) you need to load more than just the bare kernel during boot.


Cheers,

Brendan

smwikipedia wrote:Why not just directly load a file into memory? Why do we need to use extra steps to store the file in the ram disk and then load and parse the ram disk to get the file?

Compare ramdisks:
- 1 (tool) collects files needed at boot
- 2 (tool) compiles them into an image
- 3 (tool) adds filesystem index
- 4 (bootloader) copies entire image into RAM
- 5 (kernel) read ramdisk index for a file
- 6 (kernel) read file

and boot modules (see grub):
- 2 (tool) copy files and information to the boot media
- 1 (bootloader) find out which files to load into ram
- 4 (bootloader) load each file into ram
- 3 (bootloader) create a table with filenames and their locations
- 5 (kernel) look up filename in table
- 6 (kernel) read file

You see what I see? The only real difference is where the task is performed.