Two different types of device drivers
 

Hi,

I feel that there are two different types of device drivers.

Type 1: the device driver provides userspace API such as .read, .write and .ioctl. The driver is assigned a major/minor number and userspace program may access physical devices by use the API it provides.

Type 2: the device driver doesn't not provide user space API (no read, write or .ioctl), and the driver is used by another driver in the kernel.

So how do I categorize these two types of drivers? What are the correct technical terms for them?

Thanks,
Wei

Depending on how you perceive things, there are a few different type of device drivers. I've always thought there were: character, block, and network device driver categories; however it's been a while and mainly I dealt with character drivers, which are of the read/write/ioctl variety.

Here are some references:

http://www.tldp.org/LDP/khg/HyperNew...s/devices.html
http://www.tldp.org/LDP/tlk/dd/drivers.html

Those layered drivers... such as the device drivers handled by the SCSI module (each SCSI device has its own driver, and USB/ATAPI drivers, SATA drivers...).

The drivers are device drivers, which interface to the device by passing command packets to the middle layer driver (the controller driver) that hand off those packets to the physical device over the peripheral bus (USB/SCSI/SATA/ATAPI or PATA and others).

As I understand it, the controller drivers still provide the read/write/... device operations as that is how the procfs and sysfs provides access to controller configuration/statistics (/proc/bus, and /sys/bus).

Also note - the controller drivers provide global functions that implement the interface to the specific controller for the layered drivers (for USB, they are "usb_<function name>") and it is up to the device driver to register with the controller driver when loaded, and unregister when being removed. This maintains a reference count for the controller driver that prevents it from being removed out from under the device drivers that are still available/active (that would cause a crash - usually due to an invalid address being used for a function call).

The "block" or "character" devices is an external designation based on how it works (it is more historical than required - but it allows devices that are primarily block oriented to be categorized that way from those that are stream oriented (everything else). It does allow for some optimization of buffer handling for block devices - but in operation there isn't that much of a difference.

Historical note: Originally drivers were put into one or two tables - The order of entry in the table defined the major number. Block drivers went into the block list, stream drivers went into the character table. But then operating modes of disk drivers allowed raw access (hence the addition of the block devices to the character table). This was partially done to allow ioctl functions (which were always unique to the driver, but not defined for the block list - at least, I don't remember an entry for it) to do really oddball things (like rewinding a disk???). Adding block devices to the character table allowed for access to functions like low level formatting disks, bad block management... Things that made sense to have access to, but outside the functions read/writing blocks of data.

PS. There is also a third major driver - one that interfaces not with a device (or controller) but interfaces with the system (procfs, devfs...) These drivers are usually built into the kernel rather than being modules that can be loaded/removed. And then there are filesystems... But now it starts getting vague as to the definition of "driver", as modules can be drivers... except when they are not (is a security module a "driver"???)