when create linux device file
===================================================================================
from: http://www.ibm.com/developerworks/linux/library/l-devfs.html developerWorks > Linux >
Using DEVFS
How device programmers can write code for the devfs environment
developerWorks
Help us improve this content
Level: Intermediate
Alessandro Rubini (rubini@gnu.org), Linux Magazine contributor
01 Aug 2000
The role of the kernel is mostly related to hardware control, as user-space programs need a way of referring to hardware devices that they wish to use. Some hardware devices are used implicitly, through interfaces such as sockets or filesystems. However, it is often necessary to refer to a hardware device directly -- such as a particular serial port or hard-disk partition. This is accomplished through the use of special device files that are usually found in the /dev directory. This article introduces devfs.
Show developerWorks content related to my search: devfsShow developerWorks content related to my search: devfs
Hide developerWorks content related to my search: devfsHide developerWorks content related to my search: devfs
Show descriptions | Hide descriptions
Show descriptions | Hide descriptions
1 - 10 of 57 search results | View all search results
1) Using DEVFS
This article introduces devfs.
2) Common threads: Advanced filesystem implementor's guide, Part 4
With the 2.4 release of Linux come a host of new filesystem possibilities, including Reiserfs, XFS, GFS, and others. These filesystems sound cool, but what exactly can they do, what are they good at, and exactly how do you go about safely using them in a production Linux environment? Daniel Robbins answers these questions by showing you how to set up these new advanced filesystems under Linux 2.4. In this installment, Daniel explains the significance and benefits of devfs, the device management filesystem, getting you ready for the next article where he'll show you how to optimally set up devfs on your system.
3) Common threads: Advanced filesystem implementor's guide, Part 5
With the 2.4 release of Linux come a host of new filesystem possibilities, including Reiserfs, XFS, GFS, and others. These filesystems sound cool, but what exactly can they do, what are they good at, and exactly how do you go about safely using them in a production Linux environment? Daniel Robbins answers these questions by showing you how to set up these new advanced filesystems under Linux 2.4. In this installment, Daniel guides you through the process of preparing your system for devfs. By the end of this article, you'll be ready to enable devfs on your system; Daniel will cover final devfs setup in detail in the next article.
4) Common threads: Advanced filesystem implementor's guide, Part 6
With the 2.4 release of Linux come a host of new filesystem possibilities, including Reiserfs, XFS, GFS, and others. These filesystems sound cool, but what exactly can they do, what are they good at, and exactly how do you go about safely using them in a production Linux environment? Daniel Robbins answers these questions by showing you how to set up these new advanced filesystems under Linux 2.4. In this installment, Daniel shows you how to use an init wrapper to (finally!) convert your system to 'devfs mode'.
5) IBM : developerWorks : Site maintenance
The IBM developerWorks Web site is currently under maintenance.
6) Redpaper - Running the Linux 2.4 Kernel on IBM eServer xSeries Servers
This redpaper is intended for technical staff within IBM, our customers, and our Business Partners who intend to make use of the latest version of the Linux kernel (V.2.4). The new kernel offers a number of features and enhancements not previously available, which make Linux even more suitable as an enterprise-class operating system. Features such as new file systems that support logical volumes and journaling, improvements to Samba, support for Asynchronous Transfer Mode (ATM) networking, and support for a wider variety of hardware all combine to increase the attractiveness of Linux for many applications. IBM has a strong commitment to Linux across all of its server platforms and nowhere more so than for the IBM eServer xSeries class of servers. xSeries systems provide an excellent platform for Linux deployment, with support for four distributions of Linux, namely, Red Hat Linux, Caldera OpenLinux, TurboLinux, and SuSE Linux. Discussions of the Linux kernel are somewhat independent of the specific distribution being used. Because of this, we have used the Red Hat distribution for many of the examples, but they are easily extrapolated to the others.
7) Redbooks - Linux on the IBM eServer iSeries Server: An Implementation Guide
Running Linux on the IBM eServer iSeries server combines the strengths of Linux and OS/400 for an integrated solution. Linux delivers excellent open source solutions, while OS/400 is a premier integrated platform for business solutions. Linux enables a new stream of e-business applications for the iSeries platform that complements its strength as an integrated core business solution. Linux applications benefit from the iSeries platform's ability to provide resource flexibility, security, reliability, and connectivity to other applications on a single server. This IBM Redbook begins with an overview of Linux, defines what open source means, and explains why using Linux on iSeries is beneficial. Then, it highlights how to install and use Linux on the iSeries server. It discusses the basic system administration tasks and Linux application development to help you manage your system and develop Linux applications on the iSeries server. It also introduces a wide range of services, such as Firewall, Apache, Samba, and e-mail, and explains the capabilities of each. This redbook is intended to help beginner and intermediate Linux users, with an OS/400 background, to implement Linux on the iSeries server.
8) Redbooks - Linux on IBM eServer zSeries and S/390: ISP/ASP Solutions
This IBM Redbook describes how Linux can be combined with z/VM on zSeries and S/390 hardware - the mainframe. This combination of hardware and operating systems enables Internet Service Providers (ISP) and Application Service providers (ASP) to more efficiently provide services. We assume a broad definition of ASP to include production enterprise solutions as simple as file serving. In a world of discrete servers, when a new resource is required, workload can either be added to an existing server or a new one can be purchased. Often a new server is installed and the server farm grows in the enterprise. S/390 and zSeries hardware, microcode and software allow physical resources to be made virtual among Linux systems. This allows many hundreds of Linux systems to exist on a single server. Running multiple Linux images as guests of VM/ESA or z/VM is a smart choice.
9) Redpaper - Getting Started with zSeries Fibre Channel Protocol
The purpose of this IBM Redpaper is two-fold: to provide information to help you understand the concepts of zSeries Fibre Channel Protocol support, and to show you how various SCSI devices can be configured to build a zSeries FCP environment. This document provides an overview of Fibre Channel (FC) topologies and terminology, a list of the hardware and software prerequisites, and a description of our configuration, with examples of the Linux definitions that we used when writing this paper. This Redpaper is intended for Linux administrators, system programmers, hardware planners, and system engineers who will plan and install zSeries Fiber Channel Protocol support.
10) Redbooks - OS/2 to Linux Client Transition
This IBM Redbook provides information related to the viability of Linux as a client platform. It targets technical personnel who are involved in evaluating Linux as a possible client platform. It also targets administrators and support personnel who are responsible for supporting client systems. This redbook can also be helpful to anyone who is evaluating the potential of using Linux for enterprise client systems. However, the key focus is on environments where OS/2 is currently used. Many enterprises have been using OS/2 as a stable platform for critical enterprise client applications. However, as those enterprises look to the future, they look for a platform on which they can build a strategy that is open, standards-based, secure, and provides a cost-effective solution. Linux has become successful as a server platform in many of these same enterprises. It comes as no surprise that these enterprises also want to evaluate the possibility of including Linux for many of their client systems. This redbook describes platform and functional considerations for choosing Linux as a client platform. It examines techniques and facilities for administering Linux clients, coexistence of Linux clients with other platforms, and a technique to easily install Linux clients based on the well-known OS/2-based CID methodology.
Show developerWorks source code related to my search: devfsShow developerWorks source code related to my search: devfs
Hide developerWorks source code related to my search: devfsHide developerWorks source code related to my search: devfs
Show details | Hide details
Show details | Hide details
1 - 3 of 3 source code results | Show all search results (hosted by Krugle)
1) dvbdev.c
dvbdev->fops->owner = adap->module;
list_add_tail (&dvbdev->list_head, &adap->device_list);
devfs_mk_cdev(MKDEV(DVB_MAJOR, nums2minor(adap->num, type, id)),
S_IFCHR | S_IRUSR | S_IWUSR,
"dvb/adapter%d/%s%d", adap->num, dnames[type], id);
2) dvbdev.h
#include
#include
#include
#include
#define DVB_MAJOR 212
3) elf-reloc-8.s
.long 32769
.section .sbss,"aw"
.type do_devfs, @object
.size do_devfs, 4
.align 2
The special files are not associated with data stored in the disk; rather, they correspond to particular hardware devices. When user programs access and use these special files, the operation is passed to a device driver in the system kernel. For example, when you issue an open and a read on the /dev/ttyS0 file, data is read from a serial port; the serial-port device driver is invoked whenever /dev/ttyS0 is accessed.
All UNIX systems provide a directory, conventionally called /dev, where device files are held; however, each UNIX variant uses a different name layout inside that directory. Until recently, Linux systems were required to store the /dev directory on disk. What this means is that /dev includes directory entries for every possible device driver, which may not correspond to the particular hardware available on the system.
The static nature of information stored on disk makes it difficult to dynamically add and remove device files whenever drivers are loaded and unloaded from the kernel, which makes it impossible to rearrange the layout of entries in /dev should that need arise. Another disadvantage of the disk-layout mechanism for /dev is that the driver hierarchy must be tied to the idea of major and minor device numbers, which are the means used to associate a device name to the device driver in charge of hardware operations. In Linux, major and minor numbers are currently limited to eight bits wide, and changing that figure is not trivial. This effectively limits the number of devices and different device drivers that can be used by the system.
Linux kernel version 2.3.46 introduced "device filesystem," or devfs, support in the official kernel tree. devfs provides a new filesystem type to be used for /dev. This filesystem keeps track of /dev layout and entries from within the kernel, without using on-disk storage. This means that new entries can appear in /dev as device drivers are loaded and new hardware is detected by the system. This facility is marked as experimental, and its use is expected to remain optional, as some environments (such as embedded systems) may still prefer to use the old approach.
In this article I'm going to give only a brief introduction to devfs, skipping over its setup and configuration. More detailed documentation on those issues is available elsewhere; one good source of information, for instance, is the file Documentation/filesystems/devfs/README found in newer kernel source trees.
I'll show how device programmers can write code that fits in with the devfs environment. The discussion and sample code here are based on version 2.2.14 of the kernel, which has been patched with devfs-patch-v99.11.gz, available from ftp//ftp.atnf.csiro.au/pub/people/rgooch/linux.
The sample module discussed here, called drums (short for "devfs Resources in User Module Sample") is available from ftp//ftp.linux.it/pub/People/rubini.
Registering an entry point
A device driver that wants to register its entry point within the devfs filesystem should call one of the forms of the devfs_register function. The devfs kernel interface is prototyped in the header file . Let's imagine for example that we want to register a character device driver. In this case the function to call is:
devfs_handle_t devfs_register
(devfs_handle_t dir,const char *name,
unsigned int namelen,unsigned int
flags,unsigned int major,unsigned
int minor,umode_t mode,uid_t uid,
gid_t gid,void *ops, void *info);
Given the huge list of arguments, the function can register pretty much anything and can assign the desired ownership and permissions to the file. The current version of devfs does not allow registration of directories and symbolic links using this function, but there are other functions that can create such files.
In a perfectly devfs-ized world, devfs_register would be everything that's needed to create a /dev entry point for a device. However, you may want to allow the superuser to create a non-devfs entry point, using the conventional mknod command. In order to support this, any calls to register_ chrdev or register_blkdev should be replaced by calls to devfs_ register_chrdev and devfs_register_ blkdev, respectively, which take the same arguments.
Both devfs_register_chrdev and devfs_ register_blkdev are simple wrappers around register_chrdev and register_ blkdev. They either call the old-style function or don't do anything, according to whether or not the command-line option of devfs=only has been passed to the kernel at boot time. If devfs is the only way to access devices, these functions don't do anything, so any device file created outside of devfs will not be associated to any device driver.
With this background, Listing One shows how drums registers its entry points, which include a /dev/drums directory and a few files.
devfs_register_chrdev(DRUMS_MAJOR, "drums", &drums_fops);
drums_dir = devfs_mk_dir(NULL, "drums", 0, NULL);
for (i=0; i drums_devs[i]=devfs_register(drums_dir/* parent dir*/,
drums_strings[i], DRUMS_NAME_LEN,
DEVFS_FL_NONE, DRUMS_MAJOR, i/*minor*/,
S_IFCHR | S_IRUGO, 0, 0,
&drums_fops, NULL);
}
Once registered, the devices behave pretty much like any conventional device, and you can even chown and chmod them. When you read data from any of the drums special files, you'll get back the "note" associated to the specific device, repeated over and over (see Listing Two).
borea.root# ls -l /dev/drums
total 0
cr--r--r-- 1 root root 60, 0 Jan1 1970 bam
cr--r--r-- 1 root root 60, 1 Jan1 1970 bum
cr--r--r-- 1 root root 60, 2 Jan1 1970 pam
cr--r--r-- 1 root root 60, 3 Jan1 1970 pum
cr--r--r-- 1 root root 60, 4 Jan1 1970 tam
cr--r--r-- 1 root root 60, 5 Jan1 1970 tum
borea.root# head -2 /dev/drums/bam
bam
bam
borea.root# head -100 /dev/drums/tum | uniq
tum
The implementation of drums is pretty standard: The minor number of the device being read is used to choose which string to return to user space; the string being returned is the same as drums_ strings[i] used in registering the device name, as you can see in Listing Three.
int minor = MINOR(inode->i_rdev);
if (count > DRUMS_TXT_LEN) count = DRUMS_TXT_LEN;
copy_to_user(buf, drums_strings[minor],count);
Unregistering the devices at unload time is easy. You just need to call devfs_unregister for each entry point you registered. Also, if you called devfs_register_chrdev you should now call devfs_unregister_chrdev. Unregistering is shown in Listing Four.
for (i=0; i devfs_unregister(drums_devs[i]);
devfs_unregister(drums_dir);
devfs_unregister_chrdev(DRUMS_MAJOR, "drums");
Back to top
Working without major and minor numbers
If your device is meant to be available only via devfs, you can choose to avoid major and minor numbers altogether. This is because when a devfs node is opened, the kernel doesn't need to use the device numbers, as the driver has already provided the file_operations structure that must be used to act on that device.
To get automatic device numbers, the only thing that's needed is to specify DEVFS_FL_AUTO_DEVNUM in the flags argument to devfs_register. The major and minor arguments are then ignored, and the filesystem will automatically choose a major/minor pair for your device. What is most interesting in using automatic device numbers is that the device driver can no longer base its operation on the minor number, since it won't be known at compile time.
Rather, the driver must use the private_data field that is part of the file structure. Most drivers that use the field internally assign its value at open time based on the minor number being opened, and use it in the other device methods (read, write, etc.). With devfs you are allowed to choose your private_data pointer before the device is opened, and the chosen value can be passed to devfs_register as the last argument. This allows you to associate a particular data structure with each devfs entry point and use that to determine which entry point has been accessed within the device driver.
The historical role of the device numbers is eliminated by devfs: The major number is unneeded because each device declares its operations, and similarly, the minor number is not needed because each device declares its private information. The only remaining problem may be in some user-space program, which might expect the major number to be consistent across similar devices.
In the drums module, you'll find tambourine and timpani as examples of automatic assignment of device numbers. Their appearance in the system is shown in Listing Five and the code lines that implement them are shown below in Listing Six.
borea.root# ls -l /devfs/timpani /devfs/tambourine
cr--r--r-- 1 root root 144, 3 Jan 1 1970 /devfs/tambourine
cr--r--r-- 1 root root 144, 4 Jan 1 1970 /devfs/timpani
borea.root# head -1 /devfs/timpani
boom
borea.root# head -1 /devfs/tambourine
rattle
/* init_module: register tambourine and timpani */
drums_tambourine = devfs_register(NULL, "tambourine", 0,DEVFS_FL_AUTO_DEVNUM, 0, 0,
S_IFCHR | S_IRUGO, 0, 0,&drums_fops, (void *)"rattle\n");
drums_timpani = devfs_register(NULL, "timpani", 0,DEVFS_FL_AUTO_DEVNUM, 0, 0,
S_IFCHR | S_IRUGO, 0, 0,&drums_fops, (void *)"boom\n");
/* this is the read() implementation */
txt = filp->private_data;
if (count > strlen(txt)) count = strlen(txt);
copy_to_user(buf, txt, count);
*offp += count;
return count;
The ability to work without using device numbers directly is very important, because the Linux device space is not far from exhaustion, due to its sparse nature: A major number is assigned for every device driver, even though most systems have only a dozen or so drivers installed.
Back to top
More than that
While the sample drums module shows only the basic functionality of devfs, the interface exported by devfs_ fs_kernel.h offers much more. The filesystem can host conventional files, symbolic links, and everything that can live in a conventional filesystem.
The filesystem is currently marked as experimental, even though the current devfs implementation is pretty stable. The problem with devfs as I write this is that the actual use of its features must be somehow standardized to prevent possible cluttering of the devfs name space. As a matter of fact, kernel developers are still discussing the suitability of procfs and devfs for all system configuration, in order to find the best and cleanest way to access system configuration and resources.
While non-devfs systems use less memory, and a tiny conventional /dev directory is currently still the best option for small embedded systems, the availability of devfs opens a new range of options for driver developers and simplifies users' lives in adding new device drivers to their systems, since now the driver module can do everything that is needed to grant user-space access to the hardware.
Copyright Linux Magazine ©2000
Reprinted with permission
About the author
Alessandro Rubini is an independent consultant based in Italy. He writes uninteresting device drivers and uninteresting applications like GNU barcode, which gained him his preferred email address: rubini@gnu.org
===================================================================================
from: http://hi.baidu.com/fwy434822/blog/item/a15b8813efb229846438db7f.html
linux驱动加载的方式及设备文件的创建(笔记)
驱动加载：1.静态加载 （系统启动时自动的加载动内核，自动的注册设备并创建设备接点，系统启动后应用程序可以直接运行）
2.动态加载（既模块加载，系统启动时不会进行加载驱动程序，需要人为手动加载，就是说系统启动后我们的应用程序不能直接应用驱动，而是我门必须手动的用insmod命令去加载）
其中动态加载我们又可以分为三种去研究；
1. 加载驱动后，我们自己去创建主设备号，从设备号，利用cat /proc/devices 去查看主设备号是否重复，然后根据应用程序中使用的设备名称用mknod 命令去创建设备接点。
2. 加载驱动后，驱动程序会利用register_chrdev()函数自动产生主设备号去在内核中注册设备，我们利用cat /proc/devices命令和驱动程序中注册的设备名去查询主设备号和从设备号后，在根据应用程序使用的设备名，去利用mknod去创建。（利用驱动中注册的设备名是查询自动生成的主设备号，驱动中的设备名称不一定要和创建的设备接点名相同，他们之间可以用主设备号 去关联，而应用程序的设备名称则必须和创建的设备接点名相同）
3. 加载驱动后，驱动程序利用devfs系统，这个系统可以自动的产生主设备号，然后自动的创建设备接点。我们只要用加载驱动后，直接运行应用程序就行了。
===================================================================================================
from:
linux设备文件是不是系统启动是自动创建的？
1楼 发表于 2008-4-13 03:24
linux设备文件是不是系统启动是自动创建的？
还是安装系统是就固定了？那设备文件和具体计算机无关吗？
2楼 发表于 2008-4-13 13:13
QUOTE:
原帖由 ifosn 于 2008-4-13 03:24 发表
linux设备文件是不是系统启动是自动创建的？
还是安装系统是就固定了？那设备文件和具体计算机无关吗？
早期 /dev 內的設備檔案是固定的，也就是把所有裝置檔都放一份在 /dev 內。於 kernel 2.4 開始有納入 devfs 可以於開機時依據實際週邊裝置自動建立必要的裝置檔案，也可以依據後續環境動態建立設備檔 (ex: USB disk 插入時)。
kernel 2.6 改用 userspace 的 udev 取代 kernel 2.4 的 devfs，而且搭配 /sys 等目錄結構可以達成更多功能機制。
--
3楼 发表于 2008-4-13 16:52
那难道系统关机时还要去删除/dev下的设备文件？
/dev虽然是特殊文件系统 但是设备文件还是存在硬盘上的啊
4楼 发表于 2008-4-13 17:32
QUOTE:
原帖由 ifosn 于 2008-4-13 16:52 发表
那难道系统关机时还要去删除/dev下的设备文件？
/dev虽然是特殊文件系统 但是设备文件还是存在硬盘上的啊
1. udev 會自動建立與刪除所需要與所不需要的設備檔案
2. udev 管理的 /dev 是在 ram，非 hd
--
[推广获积分] 顶部
5楼 发表于 2008-4-13 18:15
特殊文件系统是可以不存在硬盘上 的 ,比如proc。。
6楼 发表于 2008-4-14 20:21
QUOTE:
原帖由 wylhistory 于 2008-4-13 18:15 发表
特殊文件系统是可以不存在硬盘上 的 ,比如proc。。
kernel 2.6，/proc 外另外像是 /dev 與 /sys 都是這類情況 ：）
--
===================================================================================================
from:
/dev/下的设备文件是每次启动时由内核自动创建的？
标题: /dev/下的设备文件是每次启动时由内核自动创建的？
我俩个内核在/dev下的设备文件差得好远
如果你是用udev的，就会重新创建。
devfs的，好像也会，我没用过，不清楚。
是的，我就是好几次出现这个问题导致系统启动出现严重的错误。
devfs可以自动创建设备文件，你可以参看IBM developerwork，
Denial, gentoo.inc ceo的文章，他是devfs的开发者。
===================================================================================================
from:
Linux系统中设备文件管理硬件设备简介
来源：赛迪网技术社区 作者：Webmaster 时间：2007-05-15 点击： [收藏] [投稿]
设备管理是操作系统五大管理中最复杂的部分。与Unix系统一样，Linux系统采用设备文件统一管理硬件设备，从而将硬件设备的特性及管理细节对用户隐藏起来，实现用户程序与设备无关性。在Linux系统中，硬件设备分为两种，即块设备和字符设备。
1、特别文件
用户是通过文件系统与设备接口的，所有设备都作为特别文件，从而在管理上就具有一些共性。
(1)每个设备都对应文件系统中的一个索引节点，都有一个文件名。设备的文件名一般由两部分构成，第一部分是主设备号，第二部分是次设备号。
主设备号代表设备的类型，可以惟一地确定设备的驱动程序和界面，如hd表示IDE硬盘，sd表示SCSI硬盘，tty表示终端设备等；次设备号代表同类设备中的序号，如hda表示IDE主硬盘，hdb表示IDE从硬盘等。
（2）应用程序通常可以通过系统调用open( )打开设备文件，建立起与目标设备的连接。
（3）对设备的使用类似于对文件的存取。打开设备文件以后，就可以通过read( )、write( )、ioctl( )等文件操作对目标设备进行操作。
（4）设备驱动程序都是系统内核的一部分，它们必须为系统内核或它们的子系统提供一个标准的接口。例如，一个终端驱动程序必须为Linux内核提供一个文件I/O接口；一个SCSI设备驱动程序应该为SCSI子系统提供一个SCSI设备接口，同时SCSI子系统也应为内核提供文件I/O和缓冲区。
（5）设备驱动程序利用一些标准的内核服务，如内存分配等。另外，大多数Linux设备驱动程序都可以在需要时装入内核，不需要时可以卸载下来。
处于应用层的进程通过文件描述字fd与已打开文件的file结构相联系。在文件系统层，按照文件系统的操作规则对该文件进行相应处理。
对于一般文件(即磁盘文件)，要进行空间的映射—从普通文件的逻辑空间映射到设备的逻辑空间，然后在设备驱动层做进一步映射—从设备的逻辑空间映射到物理空间(即设备的物理地址空间)，进而驱动底层物理设备工作。
对于设备文件，则文件的逻辑空间通常就等价于设备的逻辑空间，然后从设备的逻辑空间映射到设备的物理空间，再驱动底层的物理设备工作。
2、设备驱动程序和内核之间的接口
Linux系统和设备驱动程序之间使用标准的交互接口。无论是字符设备、块设备还是网络设备的驱动程序，当内核请求它们提供服务时，都使用同样的接口。
Linux提供了一种全新的机制，就是“可安装模块”。可安装模块是可以在系统运行时动态地安装和拆卸的内核模块。利用这个机制，可以根据需要在不必对内核重新编译连接的条件下，将可安装模块动态插入运行中的内核，成为其中一个有机组成部分，或者从内核卸载已安装的模块。设备驱动程序或与设备驱动紧密相关的部分(如文件系统) 都是利用可安装模块实现的。
在应用程序界面上，利用内核提供的系统调用来实现可安装模块的动态安装和拆卸。但通常情况下，用户是利用系统提供的插入模块工具和移走模块工具来装卸可安装模块。插入模块的工作主要如下：
(1) 打开要安装的模块，把它读到用户空间。这种“模块”就是经过编译但尚未连接的.o文件。
(2) 必须把模块内涉及对外访问的符号(函数名或变量名)连接到内核，即把这些符号在内核映像中的地址填入该模块需要访问这些符号的指令及数据结构中。
(3) 在内核创建一个module数据结构，并申请所需的系统空间。
(4) 最后，把用户空间中完成了连接的模块映像装入内核空间，并在内核中“登记”本模块的有关数据结构(如file_operations结构)，其中有指向执行相关操作函数的指针。
如前所述，Linux系统是一个动态的操作系统。用户根据工作中的需要，会对系统中设备重新配置，如安装新的打印机、卸载老式终端等。这样，每当Linux系统内核初启时，它都要对硬件配置进行检测，很有可能会检测到不同的物理设备，就需要不同的驱动程序。
在构建系统内核时，可以使用配置脚本将设备驱动程序包含在系统内核中。在系统启动时对这些驱动程序初始化，它们可能未找到所控制的设备，而另外的设备驱动程序可以在需要时作为内核模块装入到系统内核中。
为了适应设备驱动程序动态连接的特性，设备驱动程序在其初始化时就在系统内核中进行登记。Linux系统利用设备驱动程序的登记表作为内核与驱动程序接口的一部分，这些表中包括指向有关处理程序的指针和其它信息。
()
===================================================================================
===================================================================================
===================================================================================
===================================================================================
===================================================================================
===================================================================================
===================================================================================
===================================================================================
===================================================================================
===================================================================================
===================================================================================
===================================================================================
===================================================================================
