linux工作原理
❶ linux 虚拟文件系统的作用以及工作原理~~
虚拟文件系统（VFS）其实也可以翻译成虚拟文件系统转换（virtual filesystem switch）。可以看出来它的作用就是提供一个通用的接口来处理与Unix标准文件系统相关的所有系统调用。它所隐含的思想就是把表示很多不同种类的文件系统的共同信息放入内核；其中有一个字段火函数来支持linux所支持的所有实际文件系统所提供的任何操作。对所调用的每个读写或者其他函数，内核都能把它们替换成支持本地linux文件系统，NTFS文件系统或者文件所在的任何文件系统的实际函数。
至于vfs的工作原理 就不是三言两语可以解释清楚的了、里面包含了很多知识包括文件系统、超级块、i节点等等知识。其实主要就是用户安装了不同的文件系统，每个特定文件系统上都实现了包括open（） close（），read（），write（）等等的操作，在安装的时候，每个特定的文件系统会在虚拟文件系统上注册，当用户需要对特定文件系统进行操作时 只需调用统一的系统调用，虚拟文件系统能够调用对应文件系统上的函数来对文件进行操作。详细的工作原理和实现 楼主需要花时间去学一学操作系统知识可一参考《深入理解Linux内核》《深入linux内核架构》等书
❷ 在linux下,NetworkManager是怎么工作的 能否告诉我他的工作方式和工作原理.
什么是NetworkManager?
NetworkManager由几个部分组成：一个管理系统网络连接、并且将其状态通过D-BUS进行报告的后台服务，以及一个允许用户管理网络连接的客户端程序。开发NetworkManager的初衷是简化网络连接的工作，让桌面本身和其他应用程序能感知网络。
绝大部分用户不必关心NetworkManager的后台服务，他们只通过GUI的applets来管理网络连接。对于GNOME和Xfce那就是 nm-applet工具，而对于KDE用户来说就是KNetworkManager了。
许多Linux用户不记得，甚至根本不曾认识到在早期Linux里面管理网络连接时的那种折腾与痛苦。尤其是对于笔记本用户这种需要连接到两个甚至更多网 络的情况。虽然早期版本的NetworkManager用起来也是一种痛苦（那个时候曾经有个外号叫NetworkMangler，即网络磨肉机），不过现在它已经成为了一个强大的工具，让管理网络不再痛苦。
比如说吧，我记得两年前我把我的Verizon无线EV-DO卡装入openSUSE 11.0的时候，NetworkManager根本不需要任何设置。它识别了这张卡，并且出现在GNOME工具栏的下拉菜单里面，唯一须要进行的操作就是 点击“连接”。这是这些年来我碰到的最简单的配置无线网卡的方式。
不过总是有需要改进的地方，因此NetworkManager也在继续发展。即将到来的0.8.1版本已经可以在Fedora 13中找到，带来了许许多多的改进和新功能。
0.8.1的新功能
最新版本的NetworkManager包括了许多新的特征，其中绝大部分都跟支持更多的的网络设备有关。移动用户将会很喜欢这个版本，因为 0.8.1增加了用于GSM、UMTS和CDMA卡等移动宽带设备ModemManager的支持。使用ModemManager也有新的功能，比如信号强度显示和选择2G/3G模式的功能。最后（当然并不止这些），你还可以关掉漫游功能以避免产生额外的连接费用。
0.8.1还支持使用蓝牙，不仅支持个人区域网络(PAN)上网，也支持老的蓝牙拨号网络(DUN)协议。所有（或者说最多）支持的设备可以在 wiki上找到。
如果你是为数不多的使用IPv6联网的用户之一（事实上他们发誓以后每个人都会用上），你会很高兴地发现现在NetworkManager支持 IPv6的自动配置和静态IP了。0.8.1版本还会带来IPv6的DHCP支持。
尽管大多数最近的改变都是增强设备或者协议的支持，可0.8.1也同样给我们代来了一个新的漂亮的客户端界面。
命令行接口
在我看来，0.8.1中最有趣的特征是nmcli，一个NetworkManager的命令行接口。虽然NetworkManager在管理网络连接方面有着巨大的飞跃，但是有一点倒退到老风格的管理方式的是忽略了命令行接口。只用GUI配置网络有错吗？
有几个问题。一部分用户可能没有使用能够方便地支持NetworkManager的applet的桌面环境或者窗口管理器。有些人或者根本就没有使用GUI环境。用户也有可能想通过编写脚本的方式来管理网络接口，如果唯一可用的控制器是GUI的话这会变得非常困难。
终于，NetworkManager有了自己 的CLI工具，nmcli。使用nmcli用户可以查询网络连接的状态，也可以用来管理。这个工具依然有点原始，不过其语法相对简单，并且对于那些真正需 要在CLI中使用NetworkManager的人来说并不太难掌握。比如，列举系统中的网络接口只需要运行：
nmcli dev list就会显示一些类似于下面的输出:
- Device: eth0 -----------------------------------------------------------------
Type 802-3-ethernet
Driver pcnet32
State connected
Default no
HW Address 00:0C:29:C3:87:30
Capabilities:
Carrier Detect yes
Wired Properties
Carrier on
IPv4 Settings:
Address 172.16.146.140
Prefix 24 (255.255.255.0)
Gateway 172.16.146.2
DNS 172.16.146.2
如果你想要关闭一个连接，你可以使用诸如nmcli con down id <id>的东西, 这里<id>是某个连接的ID。nmcli现在还不像ifconfig那样灵活和功能完善，不过这仅仅是一个开始。
展望未来
毫无疑问，NetworkManager尚未完成，或许永远也不可能完成。总有新的设备需要支持，新的功能需要增加。另外，NetworkManager在让许多用户在使用主流、标准的网络配置时变得简便，但未必适应那些不常见的配置。
比如，很有可能在0.8.2或者以后版本中出现的功能有 网络接口bonding 和为一个以太网接口 同时分配一个PPPoE地址和本地地址。
不管怎么说，NetworkManager已经成为Linux桌面的一项杀手级功能。如果你不曾想过管理家里，办公室和旅途中的各种网络连接是多么的复杂，那么你可以感谢NetworkManager，是它让你的生活变得更加轻松。
❸ 请问linux是如何产生和其发展的过程
一、简单的说： 一个名叫Linus Torvalds 的芬兰大学生想要了解Intel的新CPU386。他认为比较好的学习方法是自己编写一个操作系统的内核。出于这种目的，加上他对当时Unix 变种版本（即Minix）对于80386类机器的脆弱支持十分不满，他决定要开发出一个全功能的、支持POSIX标准的、类Unix的操作系统内核，该系统吸收了BSD和System V的优点，同时摒弃了它们的缺点。Linus独立把这个内核开发到0.02 版，这个版本已经可以运行gcc、bash 和很少的一些应用程序。这些就是他开始的全部工作了。后来，他又开始在因特网上寻求广泛的帮助。
二、具体的分析： Linux 操作系统的诞生、发展和成长过程依赖于以下五个重要支柱：
UNIX 操作系统、 MINIX操作系统、 GNU 计划、 POSIX 标准 、 Internet 网络。
UNIX操作系统
Linux 操作系统是UNIX 操作系统的一个克隆版本。UNIX 操作系统是美国贝尔实验室的Ken.Thompson和Dennis Ritchie 于1969 年夏在DEC PDP-7 小型计算机上开发的一个分时操作系统。Ken Thompson 为了能在闲置不用的PDP-7 计算机上运行他非常喜欢的星际旅行（Space travel）游戏，于是在1969 年夏天乘他夫人回家乡加利福尼亚渡假期间，在一个月内开发出了UNIX 操作系统的原型。当时使用的是BCPL 语言（基本组合编程语言），后经Dennis Ritchie 于1972 年用移植性很强的c语言进行了改写，使得UNIX 系统在大专院校得到了推广。
MINIX操作系统
MINIX 系统是由Andrew S. Tanenbaum（AST）开发的。AST 是在荷兰Amsterdam 的Vrije 大学数学与计算机科学系统工作，是ACM 和IEEE 的资深会员(全世界也只有很少人是两会的资深会员)。MINIX 是他1987 年编制的，主要用于学生学习操作系统原理。到1991 年时版本是1.5。目前主要有两个版本在使用：1.5 版和2.0 版。当然目前MINIX 系统已经是免费的，可以从许多FTP 上下载。
对于Linux 系统，他后来曾表示对其开发者Linus的称赞。但他认为Linux的发展很大原因是由于他为了保持MINIX 的小型化，能让学生在一个学期内就能学完，因而没有接纳全世界许多人对MINIX的扩展要求。因此在这样的前提下激发了Linus 编写Linux 系统。当然Linus 也正好抓住了这个好时机。
作为一个操作系统，MINIX 并不是优秀者，但它同时提供了用C 语言和汇编语言编写的系统源代码。这是第一次使得有抱负的程序员或hacker 能够阅读操作系统的源代码。在当时，这种源代码是软件商们一直小心守护着的秘密。
GNU计划
软件产业在70年代成就了两位针锋相对的领袖人物，来自哈佛大学的比尔·盖茨和Richard M.Stallman。前者宣布了Copyright(版权)时代的到来，并构建了微软帝国的辉煌；后者于1984年创立自由软件体系GNU，拟定普遍公用版权协议（GeneralPublicLicense，简称GPL），今天Linux的成功就得益于GPL协议。
所有GPL协议下的自由软件都遵循着Richard M. Stallman的"Copyleft"(非版权)原则：即自由软件允许用户自由拷贝、修改和销售，但是对其源代码的任何修改都必须向所有用户公开。
GNU 计划和自由软件基金会FSF(the Free Software Foundation)是由Richard M. Stallman 于1984 年一手创办的。旨在开发一个类似UNIX 并且是自由软件的完整操作系统：GNU 系统（GNU 是"GNU's Not Unix"的递归缩写，它的发音为"guh-NEW"）。
各种使用Linux 作为核心的GNU 操作系统正在被广泛的使用。虽然这些系统通常被称作"Linux"，但是Stallman 认为，严格地说，它们应该被称为GNU/Linux系统。
到上世纪90 年代初，GNU 项目已经开发出许多高质量的免费软件，其中包括有名的emacs 编辑系统、bash shell 程序、gcc 系列编译程序、gdb 调试程序等等。这些软件为Linux 操作系统的开发创造了一个合适的环境。这是Linux 能够诞生的基础之一，以至于目前许多人都将Linux 操作系统称为“GNU/Linux”操作系统。
POSIX标准
POSIX（Portable Operating System Interface for Computing Systems）是由IEEE 和ISO/IEC 开发的一簇标准。该标准是基于现有的UNIX 实践和经验，描述了操作系统的调用服务接口。用于保证编制的应用程序可以在源代码一级上在多种操作系统上移植和运行。它是在1980 年早期一个UNIX 用户组(usr/group)的早期工作基础上取得的。该UNIX 用户组原来试图将AT&T 的System V 操作系统和BerkeleyCSRG 的BSD 操作系统的调用接口之间的区别重新调和集成。并于1984 年定制出了/usr/group 标准。
关于POSIX标准的制定过程：略。
在90 年代初，POSIX 标准的制定正处在最后投票敲定的时候，那是1991-1993 年间。此时正是Linux刚刚起步的时候，这个UNIX 标准为Linux 提供了极为重要的信息，使得Linux 能够在标准的指导下进行开发，并能够与绝大多数UNIX 操作系统兼容。在最初的Linux 内核源代码中（0.01 版、0.11 版）就已经为Linux 系统与POSIX 标准的兼容做好了准备工作。在Linux 0.01 版内核的/include/unistd.h 文件中就已经定义了几个有关POSXI 标准要求的符号常数，而且Linus 在注释中已写道：“OK，这也许是个玩笑，但我正在着手研究它呢”。
可参考下《Linux就该这么学》了解更详细的Linux知识。
❹ linux下c语言编译器的工作原理是怎么样的/
c语言编译器的工作原理都差不多的。一般来说分为四个阶断；
1、预处理阶断，主要是文本替换操作。有预处理器完成。
2、编译阶断，将C源码生成汇编代码，这个是有C语言编译器来完成的，默认linux下是cc。
3、汇编阶断，将汇编代码，生成相应的可执行体，即二进制文件。
这个过程都可以自己通过给gcc加入参数来详细的获取这些过程的，具体可以参考：http://jingyan..com/article/03b2f78c1d6ede5ea237aed7.html
❺ linux 管道原理
Linux原理的学习，我打算由浅入深，从上之下，也就是先了解个大概再逐个深入。先了解一下Linux的进程先。
一、Linux进程上下文
Linux进程上下文，我理解就是进程组成元素的集合。包括进程描述符tast_struct，正文段，数据段，栈，寄存器内容，页表等。
1）tast_struct
它是一种数据结构，存储着进程的描述信息，例如pid，uid，状态，信号项，打开文件表等。是进程管理和调度的重要依据。
2）用户栈和核心栈
顾名思义，用户栈是进程运行在用户态使用的栈，含有用户态执行时候函数调用的参数，局部变量等；核心栈是该进程运行在核心态下用的栈，保存调用系统函数所用的参数和调用序列。这两个栈的指针都保存在tast_struct结构中。
3）寄存器
保存程序计数器，状态字，通用寄存器，栈指针。
4）页表
线性地址到物理地址的映射
5）正文段，数据段。
二、Linux进程的状态
Linux中进程共有5个状态：就绪，可中断睡眠，不可中断睡眠，暂停，僵死。也就是说，linux不区分就绪和运行，它们统一叫做就绪态。进程所处的状态记录在tast_struct中。
三、进程的控制
1）进程树的形成
计算机启动后，BIOS从磁盘引导扇区加载系统引导程序，它将Linux系统装入内存，并跳到内核处执行，Linux内核就执行初始化工作：初始化硬件、初始化内部数据结构、建立进程0。进程0创建进程1，进程1是以后所有创建的进程的祖先，它负责初始化所有的用户进程。进程1创建shell进程，shell进程显示提示符，等待命令的输入。
2）进程的创建
任何一个用户进程的创建都是由现有的一个进程完成的，进程的创建要经过fork和exec两个过程。Fork是为新进程分配相应的数据结构，并将父进程的相应上下文信息复制过来。Exec是将可执行文件的正文和数据转入内存覆盖它原来的（从父进程复制过来的），并开始执行正文段。
3）进程的终止
系统调用exit()就可自我终结，exit释放除了tast_struct以外的所有上下文，父进程收到子进程终结的消息后，释放子进程的tast_struct。
4）进程的调度
进程的调度是由schele()完成的，一种情况是，当处理机从核心态向用户态转换之前，它会检查调度标志是否为1，如果是1，则运行schele()，执行进程的调度。另一种情况是进程自动放弃处理机，时候进行进程调度。
进程的调度过程分为两步，首先利用相关策略选择要执行的进程，然后进行上下文的切换。
四、进程的通信
进程的通信策略主要有，消息，管道，消息队列，共享存储区和信号量。
1）信息
消息机制主要是用来传递进程间的软中断信号，通知对方发生了异步事件。发送进程将信号（约定好的符号）发送到目标进程的tast_struct中的信号项，接收进程看到有消息后就调用相应的处理程序，注意，处理程序必须到进程执行时候才能执行，不能立即响应。
2）管道
我理解就是两个进程使用告诉缓冲区中的一个队列（每两个进程一个），发送进程将数据发送到管道入口，接收进程从管道出口读数据。
3） 消息队列
消息队列是操作系统维护的一个个消息链表，发送进程根据消息标识符将消息添加到制定队列中，接收进程从中读取消息。
4）共享存储区
在内存中开辟一个区域，是个进程共享的，也就是说进程可以把它附加到自己的地址空间中，对此区域中的数据进行操作。
5）信号量
控制进程的同步。
❻ Linux驱动程序的工作原理
由于你的问题太长我只好转载别人的手打的太累不好意思~~~
Linux是Unix***作系统的一种变种,在Linux下编写驱动程序的原理和
思想完全类似于其他的Unix系统,但它dos或window环境下的驱动程序有很大的
区别.在Linux环境下设计驱动程序,思想简洁,***作方便,功芤端口芮看?但是
支持函数少,只能依赖kernel中的函数,有些常用的***作要自己来编写,而且调
试也不方便.本人这几周来为实验室自行研制的一块多媒体卡编制了驱动程序,
获得了一些经验,愿与Linux fans共享,有不当之处,请予指正.
以下的一些文字主要来源于khg,johnsonm的Write linux device driver,
Brennan's Guide to Inline Assembly,The Linux A-Z,还有清华BBS上的有关
device driver的一些资料. 这些资料有的已经过时,有的还有一些错误,我依
据自己的试验结果进行了修正.
一. Linux device driver 的概念
系统调用是***作系统内核和应用程序之间的接口,设备驱动程序是***作系统
内核和机器硬件之间的接口.设备驱动程序为应用程序屏蔽了硬件的细节,这样
在应用程序看来,硬件设备只是一个设备文件, 应用程序可以象***作普通文件
一样对硬件设备进行***作.设备驱动程序是内核的一部分,它完成以下的功能:
1.对设备初始化和释放.
2.把数据从内核传送到硬件和从硬件读取数据.
3.读取应用程序传送给设备文件的数据和回送应用程序请求的数据.
4.检测和处理设备出现的错误.
在Linux***作系统下有两类主要的设备文件类型,一种是字符设备,另一种是
块设备.字符设备和块设备的主要区别是:在对字符设备发出读/写请求时,实际
的硬件I/O一般就紧接着发生了,块设备则不然,它利用一块系统内存作缓冲区,
当用户进程对设备请求能满足用户的要求,就返回请求的数据,如果不能,就调用请求函数来进行实际
的I/O***作.块设备是主要针对磁盘等慢速设备设计的,以免耗费过多的CPU时间
来等待.
已经提到,用户进程是通过设备文件来与实际的硬件打交道.每个设备文件都
都有其文件属性(c/b),表示是字符设备还蔤强樯璞?另外每个文件都有两个设
备号,第一个是主设备号,标识驱动程序,第二个是从设备号,标识使用同一个
设备驱动程序的不同的硬件设备,比如有两个软盘,就可以用从设备号来区分
他们.设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号
一致,否则用户进程将无法访问到驱动程序.
最后必须提到的是,在用户进程调用驱动程序时,系统进入核心态,这时不再是
抢先式调度.也就是说,系统必须在你的驱动程序的子函数返回后才能进行其他
的工作.如果你的驱动程序陷入死循环,不幸的是你只有重新启动机器了,然后就
是漫长的fsck.//hehe
(请看下节,实例剖析)
读/写时,它首先察看缓冲区的内容,如果缓冲区的数据
如何编写Linux***作系统下的设备驱动程序
Roy G
二.实例剖析
我们来写一个最简单的字符设备驱动程序.虽然它什么也不做,但是通过它
可以了解Linux的设备驱动程序的工作原理.把下面的C代码输入机器,你就会
获得一个真正的设备驱动程序.不过我的kernel是2.0.34,在低版本的kernel
上可能会出现问题,我还没测试过.//xixi
#define __NO_VERSION__
#include
#include
char kernel_version [] = UTS_RELEASE;
这一段定义了一些版本信息,虽然用处不是很大,但也必不可少.Johnsonm说所
有的驱动程序的开头都要包含,但我看倒是未必.
由于用户进程是通过设备文件同硬件打交道,对设备文件的***作方式不外乎就
是一些系统调用,如 open,read,write,close...., 注意,不是fopen, fread.,
但是如何把系统调用和驱动程序关联起来呢?这需要了解一个非常关键的数据
结构:
struct file_operations {
int (*seek) (struct inode * ,struct file *, off_t ,int);
int (*read) (struct inode * ,struct file *, char ,int);
int (*write) (struct inode * ,struct file *, off_t ,int);
int (*readdir) (struct inode * ,struct file *, struct dirent * ,int);
int (*select) (struct inode * ,struct file *, int ,select_table *);
int (*ioctl) (struct inode * ,struct file *, unsined int ,unsigned long
int (*mmap) (struct inode * ,struct file *, struct vm_area_struct *);
int (*open) (struct inode * ,struct file *);
int (*release) (struct inode * ,struct file *);
int (*fsync) (struct inode * ,struct file *);
int (*fasync) (struct inode * ,struct file *,int);
int (*check_media_change) (struct inode * ,struct file *);
int (*revalidate) (dev_t dev);
}
这个结构的每一个成员的名字都对应着一个系统调用.用户进程利用系统调用
在对设备文件进行诸如read/write***作时,系统调用通过设备文件的主设备号
找到相应的设备驱动程序,然后读取这个数据结构相应的函数指针,接着把控制
权交给该函数.这是linux的设备驱动程序工作的基本原理.既然是这样,则编写
设备驱动程序的主要工作就是编写子函数,并填充file_operations的各个域.
相当简单,不是吗?
下面就开始写子程序.
#include
#include
#include
#include
#include
unsigned int test_major = 0;
static int read_test(struct inode *node,struct file *file,
char *buf,int count)
{
int left;
if (verify_area(VERIFY_WRITE,buf,count) == -EFAULT )
return -EFAULT;
for(left = count left > 0 left--)
{
__put_user(1,buf,1);
buf++;
}
return count;
}
这个函数是为read调用准备的.当调用read时,read_test()被调用,它把用户的
缓冲区全部写1.
buf 是read调用的一个参数.它是用户进程空间的一个地址.但是在read_test
被调用时,系统进入核心态.所以不能使用buf这个地址,必须用__put_user(),
这是kernel提供的一个函数,用于向用户传送数据.另外还有很多类似功能的
函数.请参考.在向用户空间拷贝数据之前,必须验证buf是否可用.
这就用到函数verify_area.
static int write_tibet(struct inode *inode,struct file *file,
const char *buf,int count)
{
return count;
}
static int open_tibet(struct inode *inode,struct file *file )
{
MOD_INC_USE_COUNT;
return 0;
} static void release_tibet(struct inode *inode,struct file *file )
{
MOD_DEC_USE_COUNT;
}
这几个函数都是空***作.实际调用发生时什么也不做，他们仅仅为下面的结构
提供函数指针。
struct file_operations test_fops = {
NULL,
read_test,
write_test,
NULL, /* test_readdir */
NULL,
NULL, /* test_ioctl */
NULL, /* test_mmap */
open_test,
release_test, NULL, /* test_fsync */
NULL, /* test_fasync */
/* nothing more, fill with NULLs */
};
设备驱动程序的主体可以说是写好了。现在要把驱动程序嵌入内核。驱动程序
可以按照两种方式编译。一种是编译进kernel，另一种是编译成模块(moles),
如果编译进内核的话，会增加内核的大小，还要改动内核的源文件，而且不能
动态的卸载，不利于调试，所以推荐使用模块方式。
int init_mole(void)
{
int result;
result = register_chrdev(0, "test", &test_fops);
if (result < 0) {
printk(KERN_INFO "test: can't get major number ");
return result;
}
if (test_major == 0) test_major = result; /* dynamic */
return 0;
}
在用insmod命令将编译好的模块调入内存时，init_mole 函数被调用。在
这里，init_mole只做了一件事，就是向系统的字符设备表登记了一个字符
设备。register_chrdev需要三个参数，参数一是希望获得的设备号，如果是
零的话，系统将选择一个没有被占用的设备号返回。参数二是设备文件名，
参数三用来登记驱动程序实际执行***作的函数的指针。
如果登记成功，返回设备的主设备号，不成功，返回一个负值。
void cleanup_mole(void)
{
unregister_chrdev(test_major, "test");
}
在用rmmod卸载模块时，cleanup_mole函数被调用，它释放字符设备test
在系统字符设备表中占有的表项。
一个极其简单的字符设备可以说写好了，文件名就叫test.c吧。
下面编译
$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c
得到文件test.o就是一个设备驱动程序。
如果设备驱动程序有多个文件，把每个文件按上面的命令行编译，然后
ld -r file1.o file2.o -o molename.
驱动程序已经编译好了，现在把它安装到系统中去。
$ insmod -f test.o
如果安装成功，在/proc/devices文件中就可以看到设备test,
并可以看到它的主设备号,。
要卸载的话，运行
$ rmmod test
下一步要创建设备文件。
mknod /dev/test c major minor
c 是指字符设备，major是主设备号，就是在/proc/devices里看到的。
用shell命令
$ cat /proc/devices | awk "\$2=="test" {print \$1}"
就可以获得主设备号，可以把上面的命令行加入你的shell script中去。
minor是从设备号，设置成0就可以了。
我们现在可以通过设备文件来访问我们的驱动程序。写一个小小的测试程序。
#include
#include
#include
#include
main()
{
int testdev;
int i;
char buf[10];
testdev = open("/dev/test",O_RDWR);
if ( testdev == -1 )
{
printf("Cann't open file ");
exit(0);
}
read(testdev,buf,10);
for (i = 0; i < 10;i++)
printf("%d ",buf);
close(testdev);
}
编译运行，看看是不是打印出全1 ？
以上只是一个简单的演示。真正实用的驱动程序要复杂的多，要处理如中断，
DMA，I/O port等问题。这些才是真正的难点。请看下节，实际情况的处理。
如何编写Linux***作系统下的设备驱动程序
Roy G
三 设备驱动程序中的一些具体问题。
1. I/O Port.
和硬件打交道离不开I/O Port，老的ISA设备经常是占用实际的I/O端口，
在linux下，***作系统没有对I/O口屏蔽，也就是说，任何驱动程序都可以
对任意的I/O口***作，这样就很容易引起混乱。每个驱动程序应该自己避免
误用端口。
有两个重要的kernel函数可以保证驱动程序做到这一点。
1）check_region(int io_port, int off_set)
这个函数察看系统的I/O表，看是否有别的驱动程序占用某一段I/O口。
参数1：io端口的基地址，
参数2：io端口占用的范围。
返回值：0 没有占用， 非0，已经被占用。
2）request_region(int io_port, int off_set,char *devname)
如果这段I/O端口没有被占用，在我们的驱动程序中就可以使用它。在使用
之前，必须向系统登记，以防止被其他程序占用。登记后，在/proc/ioports
文件中可以看到你登记的io口。
参数1：io端口的基地址。
参数2：io端口占用的范围。
参数3：使用这段io地址的设备名。
在对I/O口登记后，就可以放心地用inb(), outb()之类的函来访问了。
在一些pci设备中，I/O端口被映射到一段内存中去，要访问这些端口就相当
于访问一段内存。经常性的，我们要获得一块内存的物理地址。在dos环境下，
（之所以不说是dos***作系统是因为我认为DOS根本就不是一个***作系统，它实
在是太简单，太不安全了）只要用段：偏移就可以了。在window95中，95ddk
提供了一个vmm 调用 _MapLinearToPhys,用以把线性地址转化为物理地址。但
在Linux中是怎样做的呢？
2 内存***作
在设备驱动程序中动态开辟内存，不是用malloc，而是kmalloc，或者用
get_free_pages直接申请页。释放内存用的是kfree，或free_pages. 请注意，
kmalloc等函数返回的是物理地址！而malloc等返回的是线性地址！关于
kmalloc返回的是物理地址这一点本人有点不太明白：既然从线性地址到物理
地址的转换是由386cpu硬件完成的，那样汇编指令的***作数应该是线性地址，
驱动程序同样也不能直接使用物理地址而是线性地址。但是事实上kmalloc
返回的确实是物理地址，而且也可以直接通过它访问实际的RAM，我想这样可
以由两种解释，一种是在核心态禁止分页，但是这好像不太现实；另一种是
linux的页目录和页表项设计得正好使得物理地址等同于线性地址。我的想法
不知对不对，还请高手指教。
言归正传，要注意kmalloc最大只能开辟128k-16，16个字节是被页描述符
结构占用了。kmalloc用法参见khg.
内存映射的I/O口，寄存器或者是硬件设备的RAM(如显存)一般占用F0000000
以上的地址空间。在驱动程序中不能直接访问，要通过kernel函数vremap获得
重新映射以后的地址。
另外，很多硬件需要一块比较大的连续内存用作DMA传送。这块内存需要一直
驻留在内存，不能被交换到文件中去。但是kmalloc最多只能开辟128k的内存。
这可以通过牺牲一些系统内存的方法来解决。
具体做法是：比如说你的机器由32M的内存，在lilo.conf的启动参数中加上
mem=30M，这样linux就认为你的机器只有30M的内存，剩下的2M内存在vremap
之后就可以为DMA所用了。
请记住，用vremap映射后的内存，不用时应用unremap释放，否则会浪费页表。
3 中断处理
同处理I/O端口一样，要使用一个中断，必须先向系统登记。
int request_irq(unsigned int irq ,
void(*handle)(int,void *,struct pt_regs *),
unsigned int long flags,
const char *device);
irq: 是要申请的中断。
handle：中断处理函数指针。
flags：SA_INTERRUPT 请求一个快速中断，0 正常中断。
device：设备名。
如果登记成功，返回0，这时在/proc/interrupts文件中可以看你请求的
中断。
4一些常见的问题。
对硬件***作，有时时序很重要。但是如果用C语言写一些低级的硬件***作
的话，gcc往往会对你的程序进行优化，这样时序就错掉了。如果用汇编写呢，
gcc同样会对汇编代码进行优化，除非你用volatile关键字修饰。最保险的
办法是禁止优化。这当然只能对一部分你自己编写的代码。如果对所有的代码
都不优化，你会发现驱动程序根本无法装载。这是因为在编译驱动程序时要
用到gcc的一些扩展特性，而这些扩展特性必须在加了优化选项之后才能体现
出来。
关于kernel的调试工具，我现在还没有发现有合适的。有谁知道请告诉我，
不胜感激。我一直都在printk打印调试信息，倒也还凑合。
关于设备驱动程序还有很多内容，如等待/唤醒机制，块设备的编写等。
我还不是很明白，不敢乱说。
❼ 解释一下linux驱动程序结构框架及工作原理
一、Linux device driver 的概念
系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以象操作普通文件一样对硬件设备进行操作。设备驱动程序是内核的一部分，它完成以下的功能:
1、对设备初始化和释放；
2、把数据从内核传送到硬件和从硬件读取数据；
3、读取应用程序传送给设备文件的数据和回送应用程序请求的数据；
4、检测和处理设备出现的错误。
在Linux操作系统下有三类主要的设备文件类型，一是字符设备，二是块设备，三是网络设备。字符设备和块设备的主要区别是:在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了，块设备则不然，它利用一块系统内存作缓冲区，当用户进程对设备请求能满足用户的要求，就返回请求的数据，如果不能，就调用请求函数来进行实际的I/O操作。块设备是主要针对磁盘等慢速设备设计的，以免耗费过多的CPU时间来等待。
已经提到，用户进程是通过设备文件来与实际的硬件打交道。每个设备文件都都有其文件属性(c/b)，表示是字符设备还是块设备?另外每个文件都有两个设备号，第一个是主设备号，标识驱动程序，第二个是从设备号，标识使用同一个设备驱动程序的不同的硬件设备，比如有两个软盘，就可以用从设备号来区分他们。设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号一致，否则用户进程将无法访问到驱动程序。
最后必须提到的是，在用户进程调用驱动程序时，系统进入核心态，这时不再是抢先式调度。也就是说，系统必须在你的驱动程序的子函数返回后才能进行其他的工作。如果你的驱动程序陷入死循环，不幸的是你只有重新启动机器了，然后就是漫长的fsck。
二、实例剖析
我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理。把下面的C代码输入机器，你就会获得一个真正的设备驱动程序。
由于用户进程是通过设备文件同硬件打交道，对设备文件的操作方式不外乎就是一些系统调用，如 open，read，write，close…， 注意，不是fopen， fread，但是如何把系统调用和驱动程序关联起来呢?这需要了解一个非常关键的数据结构：
STruct file_operatiONs {
int (*seek) (struct inode * ，struct file *， off_t ，int);
int (*read) (struct inode * ，struct file *， char ，int);
int (*write) (struct inode * ，struct file *， off_t ，int);
int (*readdir) (struct inode * ，struct file *， struct dirent * ，int);
int (*select) (struct inode * ，struct file *， int ，select_table *);
int (*ioctl) (struct inode * ，struct file *， unsined int ，unsigned long);
int (*mmap) (struct inode * ，struct file *， struct vm_area_struct *);
int (*open) (struct inode * ，struct file *);
int (*release) (struct inode * ，struct file *);
int (*fsync) (struct inode * ，struct file *);
int (*fasync) (struct inode * ，struct file *，int);
int (*check_media_change) (struct inode * ，struct file *);
int (*revalidate) (dev_t dev);
}
这个结构的每一个成员的名字都对应着一个系统调用。用户进程利用系统调用在对设备文件进行诸如read/write操作时，系统调用通过设备文件的主设备号找到相应的设备驱动程序，然后读取这个数据结构相应的函数指针，接着把控制权交给该函数。这是linux的设备驱动程序工作的基本原理。既然是这样，则编写设备驱动程序的主要工作就是编写子函数，并填充file_operations的各个域。
下面就开始写子程序。
#include <linux/types.h> 基本的类型定义
#include <linux/fs.h> 文件系统使用相关的头文件
#include <linux/mm.h>
#include <linux/errno.h>
#include <asm/segment.h>
unsigned int test_major = 0;
static int read_test(struct inode *inode，struct file *file，char *buf，int count)
{
int left; 用户空间和内核空间
if (verify_area(VERIFY_WRITE，buf，count) == -EFAULT )
return -EFAULT;
for(left = count ; left > 0 ; left--)
{
__put_user(1，buf，1);
buf++;
}
return count;
}
这个函数是为read调用准备的。当调用read时，read_test()被调用，它把用户的缓冲区全部写1。buf 是read调用的一个参数。它是用户进程空间的一个地址。但是在read_test被调用时，系统进入核心态。所以不能使用buf这个地址，必须用__put_user()，这是kernel提供的一个函数，用于向用户传送数据。另外还有很多类似功能的函数。请参考，在向用户空间拷贝数据之前，必须验证buf是否可用。这就用到函数verify_area。为了验证BUF是否可以用。
static int write_test(struct inode *inode，struct file *file，const char *buf，int count)
{
return count;
}
static int open_test(struct inode *inode，struct file *file )
{
MOD_INC_USE_COUNT; 模块计数加以，表示当前内核有个设备加载内核当中去
return 0;
}
static void release_test(struct inode *inode，struct file *file )
{
MOD_DEC_USE_COUNT;
}
这几个函数都是空操作。实际调用发生时什么也不做，他们仅仅为下面的结构提供函数指针。
struct file_operations test_fops = {?
read_test，
write_test，
open_test，
release_test，
};
设备驱动程序的主体可以说是写好了。现在要把驱动程序嵌入内核。驱动程序可以按照两种方式编译。一种是编译进kernel，另一种是编译成模块(moles)，如果编译进内核的话，会增加内核的大小，还要改动内核的源文件，而且不能动态的卸载，不利于调试，所以推荐使用模块方式。
int init_mole(void)
{
int result;
result = register_chrdev(0， "test"， &test_fops); 对设备操作的整个接口
if (result < 0) {
printk(KERN_INFO "test: can't get major number\n");
return result;
}
if (test_major == 0) test_major = result; /* dynamic */
return 0;
}
在用insmod命令将编译好的模块调入内存时，init_mole 函数被调用。在这里，init_mole只做了一件事，就是向系统的字符设备表登记了一个字符设备。register_chrdev需要三个参数，参数一是希望获得的设备号，如果是零的话，系统将选择一个没有被占用的设备号返回。参数二是设备文件名，参数三用来登记驱动程序实际执行操作的函数的指针。
如果登记成功，返回设备的主设备号，不成功，返回一个负值。
void cleanup_mole(void)
{
unregister_chrdev(test_major，"test");
}
在用rmmod卸载模块时，cleanup_mole函数被调用，它释放字符设备test在系统字符设备表中占有的表项。
一个极其简单的字符设备可以说写好了，文件名就叫test.c吧。
下面编译 :
$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c –c表示输出制定名，自动生成.o文件
得到文件test.o就是一个设备驱动程序。
如果设备驱动程序有多个文件，把每个文件按上面的命令行编译，然后
ld ?-r ?file1.o ?file2.o ?-o ?molename。
驱动程序已经编译好了，现在把它安装到系统中去。
$ insmod ?–f ?test.o
如果安装成功，在/proc/devices文件中就可以看到设备test，并可以看到它的主设备号。要卸载的话，运行 :
$ rmmod test
下一步要创建设备文件。
mknod /dev/test c major minor
c 是指字符设备，major是主设备号，就是在/proc/devices里看到的。
用shell命令
$ cat /proc/devices
就可以获得主设备号，可以把上面的命令行加入你的shell script中去。
minor是从设备号，设置成0就可以了。
我们现在可以通过设备文件来访问我们的驱动程序。写一个小小的测试程序。
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
main()
{
int testdev;
int i;
char buf[10];
testdev = open("/dev/test"，O_RDWR);
if ( testdev == -1 )
{
printf("Cann't open file \n");
exit(0);
}
read(testdev，buf，10);
for (i = 0; i < 10;i++)
printf("%d\n"，buf[i]);
close(testdev);
}
编译运行，看看是不是打印出全1
以上只是一个简单的演示。真正实用的驱动程序要复杂的多，要处理如中断，DMA，I/O port等问题。这些才是真正的难点。上述给出了一个简单的字符设备驱动编写的框架和原理，更为复杂的编写需要去认真研究LINUX内核的运行机制和具体的设备运行的机制等等。希望大家好好掌握LINUX设备驱动程序编写的方法。
❽ linux 串口工作原理
那样确实就把数据发送了，简单方便就是串口的特点
mov sbuf 0xXX
把数据送到发送缓冲区之后，芯片就自己去处理发送的事情了，程序员就不用管了
串口通信的确认一般由程序员管，比如你发个0xaa过来，我收到了就回个0xbb给你，你收到0xbb，你就知道我收到了你的0xaa，类似这样
❾ Linux中vncserver的工作原理
这是我的博客，里面写了一篇关于VNC的配置方法。
http://blog.csdn.net/wfing/archive/2010/07/23/5755756.aspx
里面也有要配置的文件的详细说明