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 -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
