[openbeos] Re: Add-ons/Module problems/ideas??
- From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 31 Jul 2002 13:37:58 CDT
>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:
