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"???)
Last edited by jpollard; 06-13-2014 at 12:23 PM.
Reason: someday I will learn to type...