study in device files(1)

henry05

               
Two kinds of device files exist: block device files and character device files. Block devices transfer data in chunks, and character devices (as the name implies) transfer data one character at a time. A third device type, the network device, is a special case that exhibits attributes of both block and character devices. However, network devices are not represented by files. (two device files: block & character, other device type: network used two others device: block & character)
The old method of assigned numbers for devices where the major number usually referred to a device driver or controller, and the minor number was a particular device within that controller, is giving way to a new dynamic method called devfs. The history behind this change is that the major and minor numbers are both 8-bit
values; this allows for little more than 200 statically allocated major
devices for the entire planate. (Block and character devices each have
their own list of 256 entries.) You can find the official listing of
the allocated major and minor device numbers in /Documentation/devices.txt. (old method=> 8 bit(max: 256); major number represents by  a  device driver or controller)
The Linux Device Filesystem (devfs) has been in the kernel since version 2.3.46. devfs is not included by default in the 2.6.7 kernel build, but it can be enabled by setting CONFIG_DEVFS_FS=Y in the configuration file. With devfs, a module can register a device by name rather than a major/minor number pair. For compatibility, devfs allows the use of old major/minor numbers or generates a unique 16-bit device number on any given system.  (from 2.6.7 kernel build: register a device by name, & 16-bit device number & compatible with old)
Block Device Any
given element in a block device can be randomly referenced. A good
example of a block device is the disk drive. The filesystem name for the first IDE disk is /dev/hda. The associated major number of /dev/hda is 3, and the minor number is 0. The disk drive itself usually has a controller and is electro-mechanical by nature (block Device example=>disk driver)
Generic Block Device Layer: The device driver registers itself at driver initialization time. This adds the driver to the kernel's driver table, mapping the device number to the block_device_operations structure. The block_device_operations
structure contains the functions for starting and stopping a given block device in the system:
-------------------------------------------------------------------------
include/linux/fs.h
760  struct block_device_operations {
761   int (*open) (struct inode *, struct file *);
762   int (*release) (struct inode *, struct file *);
763   int (*ioctl) (struct inode *, struct file *, unsigned, unsigned long);
764   int (*media_changed) (struct gendisk *);
765   int (*revalidate_disk) (struct gendisk *);
766   struct module *owner;
767  };
-------------------------------------------------------------------------
The interfaces to the block device are similar to other devices. The functions open() (on line 761) and release() (on line 762) are synchronous (that is, they run to completion when called). The most important functions, read() and write(), are implemented differently with block devices because of their mechanical nature. Consider accessing a block of data from a disk drive. The amount of time it takes to position the head on the proper track and for the disk to rotate to the desired block can take a long time, from the processor's point of view. This latency is the driving force for the implementation of the system request queue. When the filesystem requests a block (or more) of data, and it is not in the local page cache, it places the request on a request queue and passes this queue on to the generic block device layer. The generic block device layer then determines the most efficient way to mechanically retrieve (or store) the information, and passes this on to the hard disk driver.
Most importantly, at initialization time, the block device driver registers a request queue handler with the kernel (specifically with the block device manager) to facilitate the read/write operations for the block device. The generic block device layer acts as an interface between the filesystem and the register level interface of the device and allows for per-queue tuning of the read and write queues to make better use of the new and smarter devices available. This is accomplished through the tagged command queuing helper utilities. For example, if a device on a given queue supports command queuing, read and write operations can be optimized to exploit the underlying hardware by reordering requests. An example of per-queue tuning in this case would be the ability to set how many requests are allowed to be pending. The file biodoc.txt under /Documentation/block> has more helpful information on this layer and information regarding changes from earlier kernels.
               
               
               
               
               
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/32126/showart_503682.html