Hi Mikkel;
Quote from
Mikkel L. Ellertson mikkel@infinity-ltd.com To: For users of Fedora fedora-list@redhat.com Subject: Re: Moving F7 Date: Wed, 26 Sep 2007
"Before that can be answered, we need your definition of drivers.
Kernel modules can provide an interface between the kernel and hardware. (Driver?) They can let the kernel access different file system formats. They can let the kernel use different networking protocols. They extend the function of the kernel. Most modules can also be built into the kernel instead.
Modules have a defined format. Most modules are written specifically for use by the Linux kernel, and are not drivers designed for something else with a C wrapper around them. (There are modules that are basically wrappers that let you use other format drivers.)
Unless extra steps are taken, modules are limited to the version of the kernel they were compiled ageist. Some kernel options also make a difference. For example, a 64 bit module in not going to work on a 32 bit processor, or be loadable by a 32 bit kernel.
It is possible to build a kernel that does not have any loadable modules, or even support for loadable modules. This works well for embedded systems where the requirements are not going to change. For a laptop, it may make sense to build a kernel optimized for the processor in the laptop, build in support for the hardware in that laptop, and for the file systems always used. You would only enable modules for the hardware you expect to be using. (No support for PCI or ISA SCSI controllers, or multi-port serial cards. But maybe support for PCMCIA and/or cardbus SCSI cards.) But while a custom kernel may make sense for a specific machine, it does not make sense for a distribution's kernel. So most things are build as modules, and you load the modules for your specific needs.
Mikkel"
Before that can be answered, we need your definition of drivers.
"A device driver, or software driver is a computer program allowing higher-level computer programs to interact with a computer hardware device.
A driver typically communicates with the device through the computer bus or communications subsystem to which the hardware is connected. When a calling program invokes a routine in the driver, the driver issues commands to the device. Once the device sends data back to the driver, the driver may invoke routines in the original calling program. Drivers are hardware-dependent and operating-system-specific. They usually provide the interrupt handling required for any necessary asynchronous time-dependent hardware interface."
http://en.wikipedia.org/wiki/Device_driver
I am not being pedantic. The above wikipedia quote pretty well sums up my understanding of a (device) driver.
My simplest example of the driver versus module question is:
I have a NVIDA graphics chip integrated into my mother board. xorg.conf tells me I am using the Fedora "nv" driver. I want to try out Beryl. I have been told to download the "nvida" proprietary driver through livna.repo. How do those two drivers fit in with the use of modules in the kernel? If those particular drivers are not applicable to the question, you should be able to, nonetheless, see what I am getting at.
William Case wrote:
My simplest example of the driver versus module question is:
I have a NVIDA graphics chip integrated into my mother board. xorg.conf tells me I am using the Fedora "nv" driver. I want to try out Beryl. I have been told to download the "nvida" proprietary driver through livna.repo. How do those two drivers fit in with the use of modules in the kernel? If those particular drivers are not applicable to the question, you should be able to, nonetheless, see what I am getting at.
Drivers can be implemented in modules, or they can be part of the core kernel, or part of the driver (again, depending how you define driver) can be in userspace. I believe the NVIDIA driver does link to the kernel through a module.
Matt Flaschen
William Case wrote:
Hi Mikkel;
"A device driver, or software driver is a computer program allowing higher-level computer programs to interact with a computer hardware device.
A driver typically communicates with the device through the computer bus or communications subsystem to which the hardware is connected. When a calling program invokes a routine in the driver, the driver issues commands to the device. Once the device sends data back to the driver, the driver may invoke routines in the original calling program. Drivers are hardware-dependent and operating-system-specific. They usually provide the interrupt handling required for any necessary asynchronous time-dependent hardware interface."
http://en.wikipedia.org/wiki/Device_driver
I am not being pedantic. The above wikipedia quote pretty well sums up my understanding of a (device) driver.
My simplest example of the driver versus module question is:
I have a NVIDA graphics chip integrated into my mother board. xorg.conf tells me I am using the Fedora "nv" driver. I want to try out Beryl. I have been told to download the "nvida" proprietary driver through livna.repo. How do those two drivers fit in with the use of modules in the kernel? If those particular drivers are not applicable to the question, you should be able to, nonetheless, see what I am getting at.
You could consider drivers a subset of modules. That is not entirely accurate, but it serve for now. (A driver may be built into the kernel, as opposed to being a module.) But a module may add functions to the kernel while not talking directly to hardware. For example, PPP is often built as a module. It does not "talk" directly to hardware, but it is usually used to make a network connection over a serial link. (Modem, null modem cable, etc.) The different flavors FAT file systems are also supported by modules. Again, this does not meet this definition of a driver.
Another class of modules implements common features used by several drivers. For example, there are many drivers for SCSI cards. They talk to scsi_mod, which has the common SCSI code that the kernel uses to talk to the drivers. Then you have the different modules that let you talk to devices attached to the SCSI bus. It is debatable if these meet this definition of drivers. They are not really talking to the hardware. Instead, they are sending commands over the SCSI bus to devices attached to it. The device could be a CD-ROM drive, a hard drive, a tape drive, a scanner, or something else. The point is, the same module is used to talk to one class of device. (With some exceptions...) If you have a tape drive, the st module talks to it, even though the tape drive may have different capacities. For example, I have used a 2G DAT tape, a 4/8G tape drive (I forget the flavor.) and a few other SCSI tape drives. They all use the same module, and for the most part, the same command set.
This is one of the reason that modules can be hard to understand. A module may talk directly to hardware. It may be a bridge between a class of drivers and the kernel. It may be a bridge between drivers, and abstracted device types. It could add support for a type of file system. It may add support for a networking protocol. It may do something else. A module may work alone, or be a "building block" that works with other modules to provide an interface between the kernel and hardware.
I don't know if this clears things up, or just adds to the confusion. I like to think of modules as building blocks that are used to build on the base (the kernel) to create new structures. (Add functions that are not built into the kernel.)
Mikkel
Hi Mikkel;
On Wed, 2007-09-26 at 22:48 -0500, Mikkel L. Ellertson wrote:
William Case wrote:
Hi Mikkel;
[Big snip]
I don't know if this clears things up, or just adds to the confusion. I like to think of modules as building blocks that are used to build on the base (the kernel) to create new structures. (Add functions that are not built into the kernel.)
Mikkel
Yes it does clear things up. Let me restate the situation. Modules are separate programs that add functionality to the kernel usually on an "as needed" basis. One of the kinds of functionality that they add is device drivers.
Put another way, the kernel is a more-or-less fixed piece of software. Drivers and other functions are also more-or-less fixed pieces of software. Modules permit flexibility between these two sets of fixed pieces of software.
I could go on but I think I've got it. The problem in understanding is that sometimes writers get sloppy in distinguishing between the go between, the module, and some of the end pieces (the driver).
William Case wrote:
Yes it does clear things up. Let me restate the situation. Modules are separate programs that add functionality to the kernel usually on an "as needed" basis. One of the kinds of functionality that they add is device drivers.
Put another way, the kernel is a more-or-less fixed piece of software. Drivers and other functions are also more-or-less fixed pieces of software. Modules permit flexibility between these two sets of fixed pieces of software.
I could go on but I think I've got it. The problem in understanding is that sometimes writers get sloppy in distinguishing between the go between, the module, and some of the end pieces (the driver).
Part of the reason for writers getting sloppy is that a driver may be a module, or built into the kernel. It is the same driver in both cases. It is just how it is built. Most things that are modules can also be built into the kernel instead. (Closed-source modules can not be built in.)
Mikkel
-
Bill Case -
Matthew Flaschen -
Mikkel