linux驱动程序中怎么做api函数供应用程序调用

linux驱动是不是让设备的功能能正常使用，并且提供api函数供应用函数调用？ 这个api函数是怎么提供的，应用程序又是怎么调用的呢？ 最常见的是ioctl 能说的清楚带你吗？比喻ioctl这个函数，驱动程序中，怎么来实现它的？ 很多内核空间的函数都有同名的系统调用。ioctl提供了对硬件的控制。 在用户空间： intioctl(intfd,unsignedlongcmd,...)在驱动程序里面： int(*ioctl)(structinode*inode,structfile*filp,unsignedintcmd,unsignedlongarg)linux所有的设备以文件方式让用户使用，一般都在/dev目录下，要 *** 作一个设备就直接读写该设备的文件。 那些文件 *** 作，如open,close,ioctl,read,write,poll等就是驱动提供给用户的接口，编写驱动就是实现这些函数的功能。 我是问怎么在自己的驱动里，写自己的函数，供用户使用 不太懂，帮顶 引用5楼xuexi000000的回复: 我是问怎么在自己的驱动里，写自己的函数，供用户使用 1、在driver里实现了函数功能，通过ioctl参数判断要调用哪一个功能 2、也可导出属性到/sys目录下进行调用 open,close,ioct

写作本文档的目的，是为了解释为什么Linux既没有二进制内核接口，也没有稳定 的内核接口。这里所说的内核接口，是指内核里的接口，而不是内核和用户空间 的接口。内核到用户空间的接口，是提供给应用程序使用的系统调用，系统调用 在 历史 上几乎没有过变化，将来也不会有变化。我有一些老应用程序是在0.9版本 或者更早版本的内核上编译的，在使用2.6版本内核的Linux发布上依然用得很好 。用户和应用程序作者可以将这个接口看成是稳定的。

你也许以为自己想要稳定的内核接口，但是你不清楚你要的实际上不是它。你需 要的其实是稳定的驱动程序，而你只有将驱动程序放到公版内核的源代码树里， 才有可能达到这个目的。而且这样做还有很多其它好处，正是因为这些好处使得 Linux能成为强壮，稳定，成熟的 *** 作系统，这也是你最开始选择Linux的原因。

只有那些写驱动程序的“怪人”才会担心内核接口的改变，对广大用户来说，既 看不到内核接口，也不需要去关心它。

既然只谈技术问题，我们就有了下面两个主题：二进制内核接口和稳定的内核源 代码接口。这两个问题是互相关联的，让我们先解决掉二进制接口的问题。

假如我们有一个稳定的内核源代码接口，那么自然而然的，我们就拥有了稳定的 二进制接口，是这样的吗？错。让我们看看关于Linux内核的几点事实：

对于一个特定的内核，满足这些条件并不难，使用同一个C编译器和同样的内核配 置选项来编译驱动程序模块就可以了。这对于给一个特定Linux发布的特定版本提 供驱动程序，是完全可以满足需求的。但是如果你要给不同发布的不同版本都发 布一个驱动程序，就需要在每个发布上用不同的内核设置参数都编译一次内核， 这简直跟噩梦一样。而且还要注意到，每个Linux发布还提供不同的Linux内核， 这些内核都针对不同的硬件类型进行了优化（有很多种不同的处理器，还有不同 的内核设置选项）。所以每发布一次驱动程序，都需要提供很多不同版本的内核 模块。

相信我，如果你真的要采取这种发布方式，一定会慢慢疯掉，我很久以前就有过 深刻的教训…

如果有人不将他的内核驱动程序，放入公版内核的源代码树，而又想让驱动程序 一直保持在最新的内核中可用，那么这个话题将会变得没完没了。 内核开发是持续而且快节奏的，从来都不会慢下来。内核开发人员在当前接口中 找到bug，或者找到更好的实现方式。一旦发现这些，他们就很快会去修改当前的 接口。修改接口意味着，函数名可能会改变，结构体可能被扩充或者删减，函数 的参数也可能发生改变。一旦接口被修改，内核中使用这些接口的地方需要同时 修正，这样才能保证所有的东西继续工作。

举一个例子，内核的USB驱动程序接口在USB子系统的整个生命周期中，至少经历 了三次重写。这些重写解决以下问题：

这和一些封闭源代码的 *** 作系统形成鲜明的对比，在那些 *** 作系统上，不得不额 外的维护旧的USB接口。这导致了一个可能性，新的开发者依然会不小心使用旧的 接口，以不恰当的方式编写代码，进而影响到 *** 作系统的稳定性。 在上面的例子中，所有的开发者都同意这些重要的改动，在这样的情况下修改代 价很低。如果Linux保持一个稳定的内核源代码接口，那么就得创建一个新的接口 ；旧的，有问题的接口必须一直维护，给Linux USB开发者带来额外的工作。既然 所有的Linux USB驱动的作者都是利用自己的时间工作，那么要求他们去做毫无意 义的免费额外工作，是不可能的。 安全问题对Linux来说十分重要。一个安全问题被发现，就会在短时间内得到修 正。在很多情况下，这将导致Linux内核中的一些接口被重写，以从根本上避免安 全问题。一旦接口被重写，所有使用这些接口的驱动程序，必须同时得到修正， 以确定安全问题已经得到修复并且不可能在未来还有同样的安全问题。如果内核 内部接口不允许改变，那么就不可能修复这样的安全问题，也不可能确认这样的 安全问题以后不会发生。 开发者一直在清理内核接口。如果一个接口没有人在使用了，它就会被删除。这 样可以确保内核尽可能的小，而且所有潜在的接口都会得到尽可能完整的测试 （没有人使用的接口是不可能得到良好的测试的）。

如果你写了一个Linux内核驱动，但是它还不在Linux源代码树里，作为一个开发 者，你应该怎么做？为每个发布的每个版本提供一个二进制驱动，那简直是一个 噩梦，要跟上永远处于变化之中的内核接口，也是一件辛苦活。 很简单，让你的驱动进入内核源代码树（要记得我们在谈论的是以GPL许可发行 的驱动，如果你的代码不符合GPL，那么祝你好运，你只能自己解决这个问题了， 你这个吸血鬼把Andrew和Linus对吸血鬼的定义链接到这里>）。当你的代码加入 公版内核源代码树之后，如果一个内核接口改变，你的驱动会直接被修改接口的 那个人修改。保证你的驱动永远都可以编译通过，并且一直工作，你几乎不需要 做什么事情。

把驱动放到内核源代码树里会有很多的好处：

正如图中看到的一样，存在着两种WiFi设备，具体是哪一类要看IEEE802.11标准的MLME如何实现。

如果直接通过硬件实现，那么设备就是硬MAC(fullMAC)设备如果通过软件的方式实现，那么设备就是软MAC(softMAC)设备。现阶段大部分无线设备都是软件实现的软MAC设备。

通常我们把Linux内核无线子系统看成两大块：cfg80211和mac80211，它们连通内核其他模块和用户空间的应用程序。

特别指出，cfg80211在内核空间提供配置管理服务，内核与应用层通过nl80211实现配置管理接口。需要记住的是，

硬MAC设备和软MAC设备都需要cfg80211才能工作。而mac80211只是一个驱动API，它只支持软件实现的软MAC设备。

接下来，我们主要关注软MAC设备。

Linux内核无线子系统统一各种WiFi设备，并处理OSI模型中最底层的MAC、PHY两层。

若进一步划分，MAC层可以分为MAC高层和MAC底层。前者负责管理MAC层无线网络的探测发现、身份认证、关联等

后者实现MAC层如ACK等紧急 *** 作。大部分情况下，硬件(如无线适配器)处理大部分的PHY层以及MAC底层 *** 作。Linux子系统实现大部分的MAC高层回调函数。

2模块间接口

从图一中我们可以看出，各个模块之间分界线很清晰，并且模块间相互透明不可见。模块之间一般不会相互影响。

举个例子，我们在WiFi设备驱动做修改(如，打补丁、添加新的WiFi驱动等)，这些变更并不会影响到mac80211模块，

所以我们根本不用改动mac80211的代码。再如，昆明北大青鸟http://www.kmbdqn.cn/建议添加一个新的网络协议理论上是不用修改套接字层以及设备无关层代码。一般情况下，内核通过一系列的函数指针实现各层之间相互透明。

---