一般都是32位平台轉到64位平台，可是我們剛好相。
我們公司最近做的分布式檔案系統，以前是在
64位平台下**，以為現在的伺服器很少有
32位平台，也就沒有過多的考慮，現在由於客戶需要，不得不修改至
32位平台。
現在總結如下，共大家學習。 1)
資料型別的定義
一般我們都用
typedef
定義資料型別
typedefunsigned char
aol_u8_t;
typedefchar
aol_s8_t;
typedefunsigned shortaol_u16_t;
typedef
shortaol_s16_t
typedefunsigned intaol_s32_t
typedefintaol_u32_t
typedefunsigned long
aol_u64_t
typedeflongaol_s64_t
這裡最大的失誤是：把
64位定義成了
long
，這就導致在
32位平台上，
64位定義成了
32位。同時到處列印資訊
printk(「ino: %lu /n」)
修改為printk(「ino: %llu /n」)
typedefunsigned long long aol_u64_t
typedef
long longaol_s64_t
2)atomic64_t
的修改在
64位中，
atomic_64_t
的實現是
long
型別，64
位，而在
32位中沒有這樣的相應的型別。
這是因為在
atomic_t
的實現是組合語言，前面加了
lock_prefix 3)
同樣的位設定操作，其型別是
void*
型別，指標型別，在
64位平台上是
64位的，在
32平台位上是
32位。
由於我們在**中定義位一般用來標識
flag
，一般定義成了
aol_u32_tflag;
或者定義成
aol_u64_tflag;
回導致問題產生。
修改的意見是：
unsigned long flag;
static __inline__ void set_bit(int nr, volatile void * addr) 4)
kmap
的使用由於在
64位平台上，沒有高階記憶體，也就是當獲取乙個
page
描述符指標，要獲取其虛擬位址是，是直接通過
page_address
獲取的char* addr= page_address(page); 這在
32位平台上如果是高階記憶體，我們知道是需要通過對映的：
char* addr = kmap
（page）;
當使用完時，需要釋放：
kunmap(page);
還有乙個問題需要注意的是：
kmap
的次數是有限制的，這是因為在高階記憶體的永久對映裡面，只保留了
4m的虛擬位址空間，所以只能對映
1024
個頁面，當沒有可以的虛擬位址時，
kmap
函式是可以睡眠的，直到有可以的虛擬位址。所以
kmap
使用一次不能超過
1024
個，負責會導致死鎖。
64位平台簡介
目前最流行的兩種64bit微處理器架構 ia 64 intel 64 ia 64 由intel和hewlett packard公司聯合開發，被使用在 itanium和 itanium 2微處理器之上。intel 64 又稱em64t amd64 ia 32e x86 64 aa 64 x64 ham...
linux64位平台移植
linux64 最大好處就是記憶體不在有 4gb的限制 32位 linux 只有4g 的虛擬位址定址空間，可以克服這個限制，但是實現起來會比較複雜，得不償失 資料模型 ilp32 lp64 llp64 ilp64 char 8 8 88 short 16 16 16 16int 32 32 32 6...
32 64位平台printf uint64的方法
在32位平台 typedef unsigned long long int uint64 t 在64位平台 typedef unsigned long int uint64 t 不同的typdef，要求在printf中使用不同的length modifier，uint64 t 在32位使用ll，在6...