linuxunbind驱动

1. 关于linux下挂载FAT32分区的问题，高手看下

你的sda2是什么格抄式的，如果是fat32的，就用
mount －t vfat ／dev／sda2 ／mnt／g
如果是ntfs的，就看你的系统支不支持，如果支持那就
mount －t ntfs－3g ／dev／sda2 ／mnt／g
还有，先看看你mnt下的g文件夹建立了没有，如果没有，就用
mkdir /mnt/g
如果不知道你sda2的格式，就用
fdisk -l

2. 嵌入式linux 蓝牙怎么开发

一.Linux对于蓝牙的支持

在Linux 2.6内核已经实现如下协议。

串口形式蓝牙设备驱动(HCI UART driver)

USB蓝牙棒驱动(HCI USB driver)

内核也实现了L2CAP,RFCOMM串口接口，以及SCO链路支持.

另外内核也直接支持BNEP(Bluetooth Network Encapsulation Protocol )，即把蓝牙网络当成一个无线局域网操作。

Linux也带了蓝牙输入设备的相关支持。

需要打开 HIDP 和HID2HCI两个选项都要打开.

DUND 把蓝牙网络当成一个拨号网络来处理。

2.蓝牙协议栈

在实现了L2CAP后，也需要一个蓝牙协议栈处理。它起什么作用呢？ 我的理解是内核封装到RFCOMM的层次，即只负责的蓝牙的包的封装与收发。至于包收上来，在蓝牙的四个阶段，如何应用的状态影响，以及如何响应正确的包，这一些事情由蓝牙协议栈来完成的。

在Linux实现蓝牙功能有多个互相竞争的蓝牙协议栈，但是影响最大是bluez.几乎已经成为Linux下的标准协议栈的代名词。

还有一个协议栈是Affix 不过用的人比较少

在应用程序级，它主要由两部分组成，一个是bluez的应用程序库，主要负责与内核的bluez通信，和bluez-util工具。即完成蓝牙四阶段处理的一些命令行工具。

3.蓝牙的概念。

配对由一方发起即可，如果本设备需要被其它设备搜索，需要有被发现功能。

二.Linux关于蓝牙命令

-------------------------------------------------

在Linux使用蓝牙最方便是使用bluez-util自带向个命令来测试。

我们这里采用市面最容易找到的蓝牙棒来做物理层设备与手机进行通讯测试。把蓝牙棒插LINUX下的USB口后，在dmesg我们会看到提示

passkey 配置项指明请求联接的设备的pin码。当采用auto模式时，将采用这个密码来联接.

3. linux下配置nfs错误

看你输入的命令好像有点问题：localhost:后面应该是没有空格的。再试试把localhost改成IP地址

4. 怎样写linux下的USB设备驱动程序

写一个USB的驱动程序最 基本的要做四件事：驱动程序要支持的设备、注册USB驱动程序、探测和断开、提交和控制urb（USB请求块）
驱动程序支持的设备：有一个结构体struct usb_device_id，这个结构体提供了一列不同类型的该驱动程序支持的USB设备，对于一个只控制一个特定的USB设备的驱动程序来说，struct usb_device_id表被定义为：
/* 驱动程序支持的设备列表 */
static struct usb_device_id skel_table [] = {
{ USB_DEVICE(USB_SKEL_VENDOR_ID, USB_SKEL_PRODUCT_ID) },
{ } /* 终止入口 */
};
MODULE_DEVICE_TABLE (usb, skel_table);
对 于PC驱动程序，MODULE_DEVICE_TABLE是必需的，而且usb必需为该宏的第一个值，而USB_SKEL_VENDOR_ID和 USB_SKEL_PRODUCT_ID就是这个特殊设备的制造商和产品的ID了，我们在程序中把定义的值改为我们这款USB的，如：
/* 定义制造商和产品的ID号 */
#define USB_SKEL_VENDOR_ID 0x1234
#define USB_SKEL_PRODUCT_ID 0x2345
这两个值可以通过命令lsusb，当然你得先把USB设备先插到主机上了。或者查看厂商的USB设备的手册也能得到，在我机器上运行lsusb是这样的结果：
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 002: ID 1234:2345 Abc Corp.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
得到这两个值后把它定义到程序里就可以了。
注册USB驱动程序：所 有的USB驱动程序都必须创建的结构体是struct usb_driver。这个结构体必须由USB驱动程序来填写，包括许多回调函数和变量，它们向USB核心代码描述USB驱动程序。创建一个有效的 struct usb_driver结构体，只须要初始化五个字段就可以了，在框架程序中是这样的：
static struct usb_driver skel_driver = {
.owner = THIS_MODULE,
.name = "skeleton",
.probe = skel_probe,
.disconnect = skel_disconnect,
.id_table = skel_table,
};
探测和断开：当 一个设备被安装而USB核心认为该驱动程序应该处理时，探测函数被调用，探测函数检查传递给它的设备信息，确定驱动程序是否真的适合该设备。当驱动程序因 为某种原因不应该控制设备时，断开函数被调用，它可以做一些清理工作。探测回调函数中，USB驱动程序初始化任何可能用于控制USB设备的局部结构体，它 还把所需的任何设备相关信息保存到一个局部结构体中，
提交和控制urb：当驱动程序有数据要发送到USB设备时（大多数情况是在驱动程序的写函数中），要分配一个urb来把数据传输给设备：
/* 创建一个urb,并且给它分配一个缓存*/
urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb) {
retval = -ENOMEM;
goto error;
}
当urb被成功分配后，还要创建一个DMA缓冲区来以高效的方式发送数据到设备，传递给驱动程序的数据要复制到这块缓冲中去：
buf = usb_buffer_alloc(dev->udev, count, GFP_KERNEL, &urb->transfer_dma);
if (!buf) {
retval = -ENOMEM;
goto error;
}

if (_from_user(buf, user_buffer, count)) {
retval = -EFAULT;
goto error;
}
当数据从用户空间正确复制到局部缓冲区后，urb必须在可以被提交给USB核心之前被正确初始化：
/* 初始化urb */
usb_fill_bulk_urb(urb, dev->udev,
usb_sndbulkpipe(dev->udev, dev->bulk_out_endpointAddr),
buf, count, skel_write_bulk_callback, dev);
urb->transfer_flags |= URB_NO_TRANSFER_DMA_MAP;
然后urb就可以被提交给USB核心以传输到设备了：
/* 把数据从批量OUT端口发出 */
retval = usb_submit_urb(urb, GFP_KERNEL);
if (retval) {
err("%s - failed submitting write urb, error %d", __FUNCTION__, retval);
goto error;
}
当urb被成功传输到USB设备之后，urb回调函数将被USB核心调用，在我们的例子中，我们初始化urb，使它指向skel_write_bulk_callback函数，以下就是该函数：
static void skel_write_bulk_callback(struct urb *urb, struct pt_regs *regs)
{
struct usb_skel *dev;

dev = (struct usb_skel *)urb->context;

if (urb->status &&
!(urb->status == -ENOENT ||
urb->status == -ECONNRESET ||
urb->status == -ESHUTDOWN)) {
dbg("%s - nonzero write bulk status received: %d",
__FUNCTION__, urb->status);
}

/* 释放已分配的缓冲区 */
usb_buffer_free(urb->dev, urb->transfer_buffer_length,
urb->transfer_buffer, urb->transfer_dma);
}
有时候USB驱动程序只是要发送或者接收一些简单的数据，驱动程序也可以不用urb来进行数据的传输，这是里涉及到两个简单的接口函数：usb_bulk_msg和usb_control_msg ，在这个USB框架程序里读操作就是这样的一个应用：
/* 进行阻塞的批量读以从设备获取数据 */
retval = usb_bulk_msg(dev->udev,
usb_rcvbulkpipe(dev->udev, dev->bulk_in_endpointAddr),
dev->bulk_in_buffer,
min(dev->bulk_in_size, count),
&count, HZ*10);

/*如果读成功，复制到用户空间 */
if (!retval) {
if (_to_user(buffer, dev->bulk_in_buffer, count))
retval = -EFAULT;
else
retval = count;
}
usb_bulk_msg接口函数的定义如下：
int usb_bulk_msg(struct usb_device *usb_dev,unsigned int pipe,
void *data,int len,int *actual_length,int timeout);
其参数为：
struct usb_device *usb_dev：指向批量消息所发送的目标USB设备指针。
unsigned int pipe：批量消息所发送目标USB设备的特定端点，此值是调用usb_sndbulkpipe或者usb_rcvbulkpipe来创建的。
void *data：如果是一个OUT端点，它是指向即将发送到设备的数据的指针。如果是IN端点，它是指向从设备读取的数据应该存放的位置的指针。
int len：data参数所指缓冲区的大小。
int *actual_length：指向保存实际传输字节数的位置的指针，至于是传输到设备还是从设备接收取决于端点的方向。
int timeout：以Jiffies为单位的等待的超时时间，如果该值为0，该函数一直等待消息的结束。
如果该接口函数调用成功，返回值为0，否则返回一个负的错误值。
usb_control_msg接口函数定义如下：
int usb_control_msg(struct usb_device *dev,unsigned int pipe,__u8 request,__u8requesttype,__u16 value,__u16 index,void *data,__u16 size,int timeout)
除了允许驱动程序发送和接收USB控制消息之外，usb_control_msg函数的运作和usb_bulk_msg函数类似，其参数和usb_bulk_msg的参数有几个重要区别：
struct usb_device *dev：指向控制消息所发送的目标USB设备的指针。
unsigned int pipe：控制消息所发送的目标USB设备的特定端点，该值是调用usb_sndctrlpipe或usb_rcvctrlpipe来创建的。
__u8 request：控制消息的USB请求值。
__u8 requesttype：控制消息的USB请求类型值。
__u16 value：控制消息的USB消息值。
__u16 index：控制消息的USB消息索引值。
void *data：如果是一个OUT端点，它是指身即将发送到设备的数据的指针。如果是一个IN端点，它是指向从设备读取的数据应该存放的位置的指针。
__u16 size：data参数所指缓冲区的大小。
int timeout：以Jiffies为单位的应该等待的超时时间，如果为0，该函数将一直等待消息结束。
如果该接口函数调用成功，返回传输到设备或者从设备读取的字节数；如果不成功它返回一个负的错误值。
这两个接口函数都不能在一个中断上下文中或者持有自旋锁的情况下调用，同样，该函数也不能被任何其它函数取消，使用时要谨慎。
我们要给未知的USB设备写驱动程序，只需要把这个框架程序稍做修改就可以用了，前面我们已经说过要修改制造商和产品的ID号，把0xfff0这两个值改为未知USB的ID号。
#define USB_SKEL_VENDOR_ID 0xfff0
#define USB_SKEL_PRODUCT_ID 0xfff0
还 有就是在探测函数中把需要探测的接口端点类型写好，在这个框架程序中只探测了批量（USB_ENDPOINT_XFER_BULK）IN和OUT端点，可 以在此处使用掩码（USB_ENDPOINT_XFERTYPE_MASK）让其探测其它的端点类型，驱动程序会对USB设备的每一个接口进行一次探测， 当探测成功后，驱动程序就被绑定到这个接口上。再有就是urb的初始化问题，如果你只写简单的USB驱动，这块不用多加考虑，框架程序里的东西已经够用 了，这里我们简单介绍三个初始化urb的辅助函数：
usb_fill_int_urb ：它的函数原型是这样的：
void usb_fill_int_urb(struct urb *urb,struct usb_device *dev,
unsigned int pipe,void *transfer_buff,
int buffer_length,usb_complete_t complete,
void *context,int interval);
这个函数用来正确的初始化即将被发送到USB设备的中断端点的urb。
usb_fill_bulk_urb ：它的函数原型是这样的：
void usb_fill_bulk_urb(struct urb *urb,struct usb_device *dev,
unsigned int pipe,void *transfer_buffer,
int buffer_length,usb_complete_t complete)
这个函数是用来正确的初始化批量urb端点的。
usb_fill_control_urb ：它的函数原型是这样的：
void usb_fill_control_urb(struct urb *urb,struct usb_device *dev,unsigned int pipe,unsigned char *setup_packet,void *transfer_buffer,int buffer_length,usb_complete_t complete,void *context);
这个函数是用来正确初始化控制urb端点的。
还有一个初始化等时urb的，它现在还没有初始化函数，所以它们在被提交到USB核心前，必须在驱动程序中手工地进行初始化，可以参考内核源代码树下的/usr/src/~/drivers/usb/media下的konicawc.c文件。

5. USB驱动的组成有哪些

在USB规范中把USB分为五个部分：控制器、控制器驱动程序、USB芯片驱动程序、USB设备和针对不同USB设备的客户驱动程序。第一、 USB芯片驱动程序：这部分组件主要是可以提供对USB的支持。第二、 USB控制器驱动程序：这部分主要是在控制器和USB设备之间建立通信信道。第三、 USB设备：这部分组件包括和PC相连的USB外围设备，主要分为：设备本身可以再接上其它的USB外围设备，另外设备本身不能再连接其它外围设备。即集线器和设备。也可以说集线器是带有连接其它外围设备的USB端口，设备是连接在计算机上的用语完成特定功能而且符合USB规范的设备单元。第四、 USB控制器：这部分主要负责执行由USB控制器驱动程序发出的命令。第五、 USB设备驱动程序：这部分组件主要是用来驱动USB设备的程序，一般来说这是由操作系统或者是USB设备制造商提供

6. 【Linux操作】---终端神器tmux

tmux（terminal multiplexer）是Linux上的终端复用神器，可从一个屏幕上管理多个终端（准确说是伪终端）。使用该工具，用户可以连接或断开会话，而保持终端在后台运行。类似的工具还有screen，个人对这二者的使用感受是，用过tmux就再也不想用screen了。

tmux的结构包括 会话 (session)、 窗口 (window)、 窗格 (pane)三部分，会话实质是伪终端的集合，每个窗格表示一个伪终端，多个窗格展现在一个屏幕上，这一屏幕就叫窗口。基本结构及状态信息如下图所示：

基本的操作无非就是对会话、窗口、窗格进行管理，包括创建、关闭、重命名、连接、分离、选择等等。

一般使用命令和快捷键进行操作，可在系统shell终端和tmux命令模式（类似vim的命令模式）下使用命令，或者在tmux终端使用快捷键。

tmux默认的快捷键前缀是 Ctrl+b (下文用 prefix 指代)，按下前缀组合键后松开，再按下命令键进行快捷操作，比如使用 prefix d 分离会话（应该写作 prefix d 而不是 prefix+d， 因为 d 键不需要与 prefix 同时按下）。

快捷键可以自定义，比如将前缀改为 Ctrl+a ，但需要保留shell默认的 Ctrl+a 快捷键，按如下所示修改~/.tmux.conf文件：

<pre style="margin: 0px; padding: 0px; overflow: auto; overflow-wrap: break-word; font-family: "Courier New" !important; font-size: 12px !important;">1 set-option -g prefix C-a 2 unbind-key C-b 3 bind-key C-a send-prefix 4 bind-key R source-file ~/.tmux.conf ; display-message "~/.tmux.conf reloaded."</pre>

现在已将原先的 Ctrl+a 用 prefix Ctrl+a 取代，即需要按两次 Ctrl+a 生效。

第4行的作用是使用 prefix r 重新加载配置文件，并输出提示，否则需要关闭会话后配置文件才能生效，也可手动加载配置文件，在tmux终端输入" prefix :" 进入命令模式，用 source-file 命令加载配置文件。

注意，将多个命令写在一起作为命令序列时，命令之间要用空格和分号分隔。

****常用命令****

tmux new 创建默认名称的会话（在tmux命令模式使用 new 命令可实现同样的功能，其他命令同理，后文不再列出tmux终端命令）

tmux new -s mysession 创建名为mysession的会话

tmux ls 显示会话列表

tmux a 连接上一个会话

tmux a -t mysession 连接指定会话

tmux rename -t s1 s2 重命名会话s1为s2

tmux kill-session 关闭上次打开的会话

tmux kill-session -t s1 关闭会话s1

tmux kill-session -a -t s1 关闭除s1外的所有会话

tmux kill-server 关闭所有会话

常用快捷键

prefix s 列出会话，可进行切换

prefix $ 重命名会话

prefix d 分离当前会话

prefix**** D 分离指定会话

prefix c 创建一个新窗口

prefix , 重命名当前窗口

prefix w 列出所有窗口，可进行切换

prefix n 进入下一个窗口

prefix p 进入上一个窗口

prefix l 进入之前操作的窗口

prefix 0~9 选择编号0~9对应的窗口

prefix . 修改当前窗口索引编号

prefix ' 切换至指定编号（可大于9）的窗口

prefix f 根据显示的内容搜索窗格

prefix & 关闭当前窗口

prefix % 水平方向创建窗格

prefix " 垂直方向创建窗格

prefix Up|Down|Left|Right 根据箭头方向切换窗格

prefix q 显示窗格编号

prefix o 顺时针切换窗格

prefix } 与下一个窗格交换位置

prefix { 与上一个窗格交换位置

prefix x 关闭当前窗格

prefix space(空格键) 重新排列当前窗口下的所有窗格

prefix ! 将当前窗格置于新窗口

prefix Ctrl+o 逆时针旋转当前窗口的窗格

prefix t 在当前窗格显示时间

prefix z 放大当前窗格(再次按下将还原)

prefix i 显示当前窗格信息

tmux list-key 列出所有绑定的键，等同于 prefix ?

tmux list-command 列出所有命令

以上为tmux的常见操作，基本可以满足大部分的工作需求，至于更高端的操作待日后再整理。

参看链接： tmux简明教程

7. 移动硬盘省电一法

本文讨论如何用软件方式断开USB设备以实现联机USB设备的节电。

买3D打印机时满减凑单，选了一个移动硬盘座。4盘位，想着把旧硬盘放上去，用来做备份用。为了全自动化，需要把移动硬盘座一直插在服务器上（服务器是Mac mini，装的Linux）。

测了下硬盘座的功率：

这个功率真不低。而且它也不会休眠节电啥的，不管有没有数据读写，一直是21W.

做备份用，其实每天只需要开机20分钟。本想用WiFi插座定时开关电源，结果硬盘座上有一个电子开关（非机械开关），上电时一定要按一下才能开机，真要命。

试了下umount，功耗也一样。

作为对比，西数的移动硬盘盒（含一个硬盘）在联机时功耗只有5.7W（这里可能有硬盘不同的因素，没有交叉对比），而且umount时功耗接近于0。所以，这个硬盘座有点鸡肋。

我甚至想到了用机械指去按一下那个开机键。但这毕竟有点杀鸡牛刀。

经过观察发现，如果硬盘座开机但不联机，功耗也是大约6W。

剩下的问题就是看能不能用软件把USB断开。

搜寻网络，发现还是有办法的。但对不同的Linux内核，办法可能不同。长话短说，我们现在应该很少有机会碰到2.6及以前的内核了。那就只关心新内核上的做法：

就是把设备标识写入USB驱动的unbind或bind文件，就能实现断开或连接USB的效果。

具体地说：

这样就可以用 bind/unbind控制了，顺便看看这个目录的内容。bind/unbind两个文件是只写的，端口编号都是一些符号链接。

在主机重启的时候，这些端口编号是有可能变化的，所以不能用固定的数字，而是要把查找魔法字符串的过程自动化。

但上面用lsusb查找的方式并不很适合于程序。对程序更友好的方式是遍历 /sys/bus/usb/drivers/usb 的子目录，看哪个子目录里的 idVendor及idProct 能和目标 VID及PID 匹配。

而在需要重新“插入”设备时，这些文件都不存在了（因为设备已断开），所以需要事先把魔法字符串保存下来。

另外，在服务器启动/重启后，需要马上将移动硬盘“断开”。

具体实现请看 这里 。

下图是通过小米ZigBee插座记录的功率历史。从4/27开始，每天凌晨一次备份任务，图中显示为一条竖线。4/27服务器有一次手动重启，所以图中有两条竖线。在4/26之前，理论上每天也只应该凌晨有一次峰值，但实际上并不规律。

下图是每日耗电。

理论上，在节电方案前应该是0.5度（21W*24h）左右。4/26因为在调试节电方案，反复重启，插拔，耗电很高是可以理解的。但平时的波动还是有点超出预期。

理论上，在节电方案后应该接近0.15度（6W*24h）。但图中相对较高的4/29都只有0.025度。这让我怀疑小米插座的功率计的准确性。

本文主要实现了通过软件断开USB移动硬盘（物理上，USB设备是一直上电和连接USB的），确认可以起到节电的效果。

这个方法适用于其它需要软件断开/连接USB设备的场合。但要注意，它并没有断开USB设备的供电（测试过手机充电），应该是相当于“数据线的断开”。所以，想用这种办法控制USB小夜灯或风扇之类的应该是不行的。