《電子技術(shù)應(yīng)用》
您所在的位置:首頁 > 可編程邏輯 > 其他 > Linux教學(xué)——探討內(nèi)核代碼

Linux教學(xué)——探討內(nèi)核代碼

2022-08-18
來源:電子技術(shù)應(yīng)用專欄作家 嵌入式Linux
關(guān)鍵詞: 內(nèi)核代碼

  最近因為要解決一個bug,需要在內(nèi)核的f_hid.c里面做一些適配,需要把這部分代碼研究透徹。

  在這幾天之前我是根本不知道什么是In端點,Out端點,以及什么是endpoint 0的,而且最近的一段時間,我一直是在寫應(yīng)用方面的代碼,也是趁著這個機會,好好拜讀這部分。

  ——

  在HID 1.0之前,是沒有什么OUT 端點的,都是用端點0來進行數(shù)據(jù)傳輸,不過端點0有一個問題,他的最大傳輸包的大小有限制。

  微信圖片_20220818152226.jpg

  謝謝我飛哥給的截圖

  之后,就有一個大佬在原來的內(nèi)核代碼上面做了一部分修改,在原來的enpoint 0 上加了一個OUT端點,意思就是說,本來從深圳到廣州有綠皮火車,但是綠皮火車一次只能裝下20個人,有一個人就發(fā)明了高鐵,高鐵一次可以裝200個人。

  這個提交的鏈接

  https://github.com/torvalds/linux/commit/99c515005857ff7d6cd5c2ba272ccab5dc0ea648

  微信圖片_20220818152245.png

  這個修改的commit里面說明了修改的原因,比如說使用端點0不能同步到字符設(shè)備,而且端點0的使用可能會導(dǎo)致數(shù)據(jù)丟失,所以加了一個OUT interrupt endpoint接口。

  重點來了

  并且這個補丁還會繼續(xù)處理SET_REPORT  接口請求事件。

  ——

  好了,上面是這個文件的第一次修改,我們的代碼里面也是用的原廠的SDK代碼修改,但是這個修改有一個問題,實際上端點0的SET REPORT并沒有正確請求,這是一個問題,但是這個問題不是Linux 代碼的問題,應(yīng)該是芯片原廠移植過來后出現(xiàn)的問題。

  之后,又有一個大佬重新對這個內(nèi)核代碼進行了改造

  提交的commit鏈接如下

  https://github.com/torvalds/linux/commit/d7428bc26fc767942c38d74b80299bcd4f01e7cb

  他的修改的主要是增加了配置選項,就是可以軟件配置使用OUT endpoint還是端點0,這主要是不同的產(chǎn)品定義可能需求會不同。

  這個改造的原因是什么呢?

  微信圖片_20220818152314.png

  有些主機設(shè)備,我們說的主機指的是USB的HOST設(shè)備,它不支持OUT endpoint 。

  還有一些蘋果產(chǎn)品,他們天然就不能使用OUT端點來傳輸。

  其他巴拉巴拉的一些大家就自己看吧。

  ——

  截圖給大家看看什么是端點0和OUT endpoint

  微信圖片_20220818152333.jpg

  ——

  寫了很多,還沒有說到我要改造什么,其實就是對這部分機制熟悉了,要修改掉因為SET REPORT導(dǎo)致的一個bug。

  這也是一些看代碼的思路吧,內(nèi)核是分成很多很多模塊的,大家想看哪些模塊,去看看commit,去看看代碼,其實挺有意思的。

  不過里面的一些命名并不是很清晰明了,比如IN這個東西,太簡潔了,不是做USB的人估計很難明白,這些還有,要是去調(diào)試HID描述符,就知道那是太要繞腦子了。

  ——問題是什么?

  還是從HID來說,上面留言說的沒問題,USB嘛,不就是一個發(fā)送,一個接口,設(shè)備到主機通過in端口,這個沒問題。

  在HID低版本的時候用的是endpoint 0端口,也不能說是低版本,即使在高版本,也是可以用endpoint 0端口的「不同之處在于低版本只有endpoint 0」,我也拿了一些競品的產(chǎn)品來看,他們也是可以通過endpoint 0來發(fā)送信息給設(shè)備端的。

  問題是,我們用的RK方案打開了out端點后不可以。

  其他產(chǎn)品在打開out端口的時候,也是可以用endpoint 0 發(fā)送數(shù)據(jù)到設(shè)備的。

  為什么我揪著這個endpoint 0發(fā)送呢?

  是因為測試發(fā)現(xiàn)通過這個端口可以使用set report 函數(shù),用這個函數(shù)來發(fā)送消息不會出現(xiàn)偶發(fā)的超時問題。

  RK是怎么回復(fù)的呢?

  他們說他們提供的方案是用endpoint 0的,都不會有問題。

  而且看了內(nèi)核代碼,確實是配置想用哪個就用哪個,用戶自己選擇,用了out ,endpoint 0 就用不了了。

  微信圖片_20220819154823.png

  人家代碼也是寫得很清楚了,就是更子的。

  ——那我們?yōu)槭裁床恢苯佑肦K的方案,直接用endpoint 0 就好了

  直接用endpoint 0我在之前的文章也說了,這樣就可以兼容MAC的電腦,也不會出現(xiàn)一些亂七八糟可能性的問題。

  但是問題是,我們的應(yīng)用程序開發(fā)的很多功能,都已經(jīng)實現(xiàn),都是用的out端點,包的長度也是1024, 這方案一搞下去,那所有人都要重寫代碼,重新測試了。

  微信圖片_20220819154851.png

  —— 后面怎么修改了?

  因為如果加上

  微信圖片_20220819154911.png

  設(shè)備是可以調(diào)用HOST的setreport接口的,我要做的,無非就是在這里判斷下數(shù)據(jù)指令,然后傳給應(yīng)用程序就好了。

  問題就出在這里,usb的一些結(jié)構(gòu)體,如果沒有好好寫,就可能影響到系統(tǒng)的東西。

  OUT端點寫入數(shù)據(jù)的時候,是直接用到req結(jié)構(gòu)體的

  微信圖片_20220819154931.png

  這段代碼在out端點接收沒有問題,但是放到setreport部分來處理就出現(xiàn)了問題。

  setreport的處理不一樣

  他給HOST來的數(shù)據(jù)在內(nèi)核重新分配了空間。

  微信圖片_20220819154949.png

  然后就針對這些不同的邏輯修改修改。

  細(xì)節(jié)就不說了

  內(nèi)核代碼不像應(yīng)用代碼,應(yīng)用的調(diào)試是比較方便的,內(nèi)核的調(diào)試涉及硬件設(shè)備就不同了,而且接口的處理也會不同,稍不注意引起的空指針問題,整個系統(tǒng)就掛了,應(yīng)用還可以用守護進程拉起來,內(nèi)核就不行,只能重啟。

  不過內(nèi)核都是C,看起來還是比較舒服的。


    更多信息可以來這里獲取==>>電子技術(shù)應(yīng)用-AET<<

微信圖片_20210517164139.jpg

微信圖片_20220706154608.jpg

電子技術(shù)應(yīng)用專欄作家  嵌入式Linux

原文鏈接:https://mp.weixin.qq.com/s/humym3KbZsEzT2XSi-texw

本站內(nèi)容除特別聲明的原創(chuàng)文章之外,轉(zhuǎn)載內(nèi)容只為傳遞更多信息,并不代表本網(wǎng)站贊同其觀點。轉(zhuǎn)載的所有的文章、圖片、音/視頻文件等資料的版權(quán)歸版權(quán)所有權(quán)人所有。本站采用的非本站原創(chuàng)文章及圖片等內(nèi)容無法一一聯(lián)系確認(rèn)版權(quán)者。如涉及作品內(nèi)容、版權(quán)和其它問題,請及時通過電子郵件或電話通知我們,以便迅速采取適當(dāng)措施,避免給雙方造成不必要的經(jīng)濟損失。聯(lián)系電話:010-82306118;郵箱:aet@chinaaet.com。

相關(guān)內(nèi)容