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

So, basically modules and drivers ARE the same thing? Just two ways
of interfacing with them due to Unix tradition? This still doesn't
entirely make sense, partly because I didn't know BeOS was that
influenced by tradition, and partly because it still seems redundant
to me. Is this something that will change in R2? I'm still trying to
find a reason why modules and drivers must exist as separate
entities, with the kernel treating the two differently.

Rudyatek

>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: