[openbeos] Re: Add-ons/Module problems/ideas??

>This brings up a simple question I was curious about (being a 
>non-driver programmer). What really is the difference between modules 
>and drivers? I know that modules are there to provide common 
>functionality to many drivers, but is that it? Seems like there's 
>something else I'm missing, otherwise why doesn't the kernel treat 
>modules and drivers as the same thing, and let them decide whether 
>they publish devices or export APIs?
>
>Rudyatek

Hmm.. good question. Here's my take on it:

The driver interface is a long standing practice from the Unix 
community. Long ago, it was decided that treating hardware devices as 
files simplified the programming interface. Rather than treating 
keyboards, mice, hard drives, etc. each as separate unique cases, the 
Unix IO model just treats them all as files that you can use open(), 
read(), write(), close(), and ioctl() on. The files are published in a 
"device" directory which is usually /dev.

Extending the kernel is a more recent idea. Allowing the kernel to 
invoke other kernel level code at run time makes the kernel more 
modular and easily enhanced by the work of others. It also reduces the 
size of the kernel by not requiring everything to be statically linked 
in with the kernel itself.

There is no requirement that drivers be dynamically loaded. Until 
recently, most drivers were build into the kernel. However, the trend 
now is definitely to let the drivers be loaded on demand at run time. 
These kind of drivers, therefore, have to be written as some kind of 
kernel extension.

Modules are the BeOS specific way of extending the kernel. With a 
module, you can write kernel level code that can be loaded and run at 
anytime. It will behave virtually no different than if the code had 
been part of the kernel proper. Most BeOS drivers are written as 
modules to allow the system to be more flexible -- only enough drivers 
needed to boot are statically linked in with the kernel. This makes the 
BeOS very flexible -- you can change hardware drivers as you go w/o 
needing to reboot.

Since the driver interface (/dev) is so well known to the programming 
community, the BeOS supports this interface too. Therefore, modules 
that wished to be accessed and programmed like a device can publish 
themselves in the /dev filesystem. It is not so much a requirement as a 
standard practice.

But not all modules have to be drivers. Some can simply export common 
code -- essentially a kernel level library.

Ok, that's my take. Anyone care to add to this or disagree?

Other related posts: