諸如 u32 u16 __u8 這類定義主要適用於什麼情況？

01-07

在寫驅動代碼時是用 __u32 還是 unsigned int 更合適？
此外 __iomem 在什麼情況下需要加上？

首先感謝一下回答者，這裡再拋出一個問題：
現在寫驅動的話使用什麼類型是最標準，最合適的？

驅動開發的原則：

能用__u32就最好用它，或者用u_int32_t之類的也可以，但不要直接用unsigned int等默認的數據類型。目的是讓別人明白，你這個變數佔多大內存。

原因：

你不能確定你的代碼未來只在一個平台上運行，它可能會被移植到非Linux平台（確實有很多人這麼做），它可能運行在不同的CPU平台，比如64位環境，非x86環境。

因為C語言中並未明確規定int一定要佔多少位元組，只是規定了long &>= int &>= short，所以__u32就是告訴別人，這變數佔4位元組。

同樣的：__iomem也是能加就加，這樣當你的驅動被別人維護的時候，別人會明白，這塊內存是用於IO的，可DMA的，而不是paged-memory。

說到底，這是一種良好的編碼風格，確實，不加這些東西，對於編譯和運行來說，可能是無任何影響的，但是，不寫注釋的代碼一樣也對編譯和運行無影響，你敢一句注釋都不寫嗎？

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

驅動中使用哪種類型最標準，這個沒有正確答案，但建議是不使用C語言原始的數據類型（char/short/int/long），而是使用有明確位元組大小的數據類型（u_int32_t/__u32/uint32_t/DWORD/UINT32均可）。保持代碼風格的一致性即可。

Linux社區提倡開放，並不嚴格限制開發者必須用哪種類型，一切都只是建議使用。

但有一種情況是例外的：開發標準庫函數，比如自己實現strlen，那麼返回值就必須是size_t，因為標準庫是標準的。

主要用於上古時代的編譯器。

& 中的 uint32_t 是 C99 標準，至今已經 15 年，多數編譯器對它有正確支持。選用 __u32 這種定義的代碼往往誕生於非常早的，沒有 uint32_t 這種標準定義的年代。

你使用 __u32 而不使用 uint32_t 的原因一般有下列幾種：

1，你需要維護一份非常老的代碼，要照顧舊的代碼的風格。

2，你的項目所使用的編譯器非常老，至今仍然不支持標準的 uint32_t 系列的類型。

一般而言，寫驅動是用 uint32_t 這樣的標準寫法，還是程序內自定義一套 __u32 之類的類型定義，取決於你使用什麼編譯器。

__u32在C++11裡面叫unsigned int32_t，意思就是說我這個東西無論如何必須處理成32位。int多長誰知道啊，這是undefined的。

諸如 __u32 __u16 __u8 這類定義主要適用於什麼情況？