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小夜燈或風扇之類的應該是不行的。