Rfkill,其中rf是Radio frequency(射頻)，主要作用是一個專門管理開關的子系統，舉例說明Android手機的通知欄可以方便地開關Airplane/BT/WiFi/Data/GPS，使用起來著實很方便。但是這是Android系統上層統一實現的，對應Linux內核以前是沒有統一的實現，隨著這種情況的增多也有專門的子系統來集中實現這個功能。這正是rfkill的工作。
上述的幾個控制例子中，或許它們每個功能被發明時都是一場革命，原理甚或配置都可能相當復雜，但是對最終的用戶來說，使用最多的也就是「開關」。
使用范例，監聽無線網卡硬件變化：
$ rfkill
Usage: rfkill [options] command
Options:
--version show version (0.4-1Ubuntu3 (Ubuntu))
Commands:
help
event
list [IDENTIFIER]
block IDENTIFIER
unblock IDENTIFIER
where IDENTIFIER is the index no. of an rfkill switch or one of:
<idx> all wifi wlan bluetooth uwb ultrawideband wimax wwan gps fm
$ rfkill event
1412007426.882932: idx 0 type 1 op 0 soft 0 hard 0
1412007465.911313: idx 0 type 1 op 2 soft 0 hard 1
1412007605.911553: idx 0 type 1 op 2 soft 0 hard 0
1412007705.911463: idx 0 type 1 op 2 soft 0 hard 1
1412007715.911449: idx 0 type 1 op 2 soft 0 hard 0
$
驅動中實現了復雜的特性驅動後，最好完善一個rfkill驅動就再好不過了。Rfkill從原理不過是一個新的sys文件系統中的class。位於/sys/class/rfkill/。因為它小，所以所說的東西也不是特別多，但是因為它引起了一段經歷讓人揪心，重點寫下來。
寫在後面：
研究這個的源由是在移植一個BT驅動的時候，出現了一個怪異的現象。由於僅僅是系統版本的升級（從Android4.2升級到Android4.4）所以可以確定硬件是完好的。相應的驅動先配置後好，燒寫系統後BT測試正常。出於「不糊弄」的心態，我決定反測試一下，在內核中將BT相關選項去掉後，測試結果BT確實是不能使用了；再將驅動配置添加上卻意外發現仍然不能正常開啟。然後立刻回退版本，測試之前能正常的內核，結果還是成功打開設備。我就開始亂想了，BT IC被我使用軟件配置壞了？出現這種詭異的事件時，答案一般都在廁所或者去廁所的路上，我得去那裡找找，順便洗把臉，找到的概率會更高。
廁所還是給了我一些指點，先確認BT的硬件IC到底有沒有問題，將系統完整地燒回Android4.2系統，測試結果是正常的。我放心一些了，然後使用第二台進行詭異事件的重新測試，把之前的系統鏡像依次燒入，現象和第一台機器是一樣的。到此刻就該是逗機靈的時刻了：一旦運行了不帶BT驅動的的鏡像，那麼再燒寫帶BT驅動的也不能正常打開驅動了——BT芯片沒有復位！！！這個是我的猜測，立刻完全斷電再上電，原來包含BT驅動的不能正常打開BT的系統鏡像可以正常打開了。
以之前的驗證結果為起點進行思考，我重新燒寫系統鏡像都是直接按「重啟鍵」（硬件上叫復位鍵）進行系統的重啟，現在發現它會引起一個問題。BT為什麼沒有在按下復位鍵的時候進行復位呢？這個同樣只是假設，萬用表伺候！先不管電路怎麼連接，直接測試BT的復位管腳，在按下復位鍵時，電壓並沒有由高電平變為低電平。這一點得到證實後，查看原理圖得知原來BT的復位管腳並不是和總復位鍵相連，而是連接到了CPU的一個GPIO上，再然後根據這個GPIO的名字查出在Android4.2的內核驅動中是要注冊成rfkill中BT的reset管腳的。照做後一切問題得以解決。
我以前的印象中一個電路板上的所有的IC的reset管腳都是統一連接到用戶的復位開關上呢！這次認識了一直以來都僅是眼熟的rfkill。原來BT的IC一直都沒有斷電和RESET導致沒有辦法正常的開啟。
