最近做了一些關於usb的方案，發現了乙個共通的問題。
由於windows的裝置驅動給每個裝置乙個裝置標識(device id)。設計的初衷是用來區分每個裝置的。
usb裝置的deviceid命名規則很簡單。舉例來說，如果乙個usb裝置的vid是0x1234、pid是0x5678、序列號是00001，則它的deviceid為：
usb\vid_1234&pid_5678\00001
由於vid是usb廠商的唯一標識、pid是廠商定義的產品的唯一標識、序列號理論上應該是同類產品的唯一標識。因此理論上說這樣的deviceid可以區分所有usb裝置。
usb\vid_1234&pid_5678\x&yyyyyyyy&z
其中x是裝置的層次、z表示裝置插到hub的哪個埠、yyyyyyyy是與hub有關的某常數。
因此，當usb的裝置描述符中指出有序列號時，就必須保證每個產品有乙個唯一的序列號。
但不幸的是，現實中序列號存在重號的情況。當乙個usb產品的程式是在maskrom內或寫入otp的話，由於maskrom和otp很難做到每個產品都有自己區別於其它相同產品的序列號。因此這種方案如果有序列號，則所有產品都是同一序列號。問題就發生了。
早期windows驅動完全沒有處理device id重名，遇到這種情況只能崩潰。例如一直沒有更新的hid裝置，一插即死。
稍後期的驅動似乎意識到這種情況的嚴重性(即便不是驅動本身的問題，驅動也不應該在這種情況下使系統崩潰)，試圖去解決它，但可惜不徹底。例如usbstor驅動，當同乙個hub上插多個相同序列號的u盤時，驅動會認為後來者沒有序列號，以為這樣就解決問題了。但它忘了hub有層次性。當兩個序列號相同的u盤插到不同hub時(包括有插主機的roothub)，驅動忘了給後來者改名了。系統還是崩潰。
難道就沒有徹底的解決辦法嗎？有。
事實上，問題的癥結不在class層而在於usb本身，即ep0列舉的處理上。微軟似乎已經認識以了這一點，因此並沒有打算在class層徹底解決問題。
解決辦法是，在登錄檔[hkey_local_machine\system\controlset001\control\usbflags]中新增：
"globaldisablesernumgen"=hex:01
"ignorehwsernum12345678"=hex:01
其中的12345678就是指vid和pid。有多少有問題的vid、pid就要增加多少項。
作這樣的處理之後，不管是hid、mass storage還是其它裝置，都沒有問題了。
但畢竟這個問題的根源不在驅動，而在於裝置firmware。因此在寫firmware的時候要留心。flash方案可以隨時公升級，問題不大；如果是otp方案，建議採用燒寫時可改寫序列號的晶元方案；是maskrom方案，則建議不要用序列號。
序列化中的序列號衝突問題
一般序列化中的序列號衝突問題大致是這樣形成的 1.假設有乙個類user，實現了序列化介面 2.這個類編譯後形成乙個位元組碼檔案，由於實現了序列化介面，在編譯後的class檔案會帶有乙個序列 id，之後載入記憶體並建立物件等 3.然後我們通過物件輸出流把物件寫到乙個檔案裡，這時候序列號 id也會被寫入...
Linux核心讀取磁碟序列號的問題
一向的觀點就是 別在核心裡面處理字串 事實上，確實應該如此！linux核心的塊裝置驅動有能力讀取磁碟的序列號，這個資料儲存在磁碟的控制晶元rom裡面。核心應該以怎樣的形式將這個序列號呈現給呼叫者呢？我們ls一下這個目錄 dev disk by id ll dev disk by id lrwxrwx...
Photoshop CS4序列號過期的問題
1 在網路上搜尋一些ps cs4序列號 如1330 1221 6824 4838 0308 6823，1330 1283 7461 4574 7002 2504，1330 1795 2880 5375 9721 5392，1330 1221 6824 4838 0308 6823，1330 1283...