カーネル・データ構造体の名前が同じでも、追加されたメンバーに備わっている拡張機能を一部のメンバーが持っていなかったり、メンバーのタイプまたはサイズが異なったりする場合があります。

カーネル関数の名前が同じでも、コールするときの構文または戻り値の構文が異なったり、関数コール時の前提条件や副次的効果に差異が見られたりする場合があります。

ドライバが既存のカーネル関数を使用しないで、かわりにオペレーティング・システム固有の文書化されていない副次的効果に依存する場合があります。

ワード・サイズやデータ型のサイズ(short、int、longなど)といったアーキテクチャ上の違いが、移植に関する問題を引き起こす可能性があります。 アドレス・ポインタやintのサイズも同じとはかぎりません。 不透明データ型(dev_t、atomic_tなど)のサイズもソース・システムとターゲット・システムで同じではない可能性があるので、これらを不透明型でないデータ型に変換するのは安全ではありません。 デフォルトのcharの有符号性もプラットフォーム間で異なる場合があります。

アーキテクチャの中には、位置合せされていないデータの使用を許可するものもあれば、許可しないものもあります。 移植性に対応するため、すべての型がサイズの倍数のメモリー・アドレス上で正しく位置合せされている必要があります。

構造体の埋込み方法がソース・システムとターゲット・システムで異なることがあり、コードで構造体の埋込み方法が想定されている場合、移植に関する問題が生じる可能性があります。

システム・アーキテクチャのエンディアンネス(Linuxシステムでは<asm/byteorder.h>に定義)が原因となり、システム間でデータ構造体が渡される場合、またはデータ処理時のデフォルトのバイト・オーダーが想定されている場合に、移植に関する問題が生じる可能性があります。

1秒当たりのタイマー割込み回数とシステム時間の内部表現がプラットフォーム間で異なる可能性があります。 時間単位のスケールを変更するには、HZ (<config/auto.conf>内のCONFIG_HZで定義された1秒当たりのタイマー割込み回数)の値を使用します。 たとえば、システムが起動してからの時間(秒単位)はグローバル変数jiffiesの値をHZで除算することで算出できます。

メモリー・ページ・サイズはプラットフォーム間で異なる可能性があり、一部のアーキテクチャでは複数のページ・サイズをサポートできます。

アーキテクチャごとに、メモリーの読み書きを行う順序を制御するプロセスの順序付けルールが異なる可能性があります。 rmb()、wmb()およびmb()の各メソッドを使用することで、メモリーの読み書きの再順序付けにバリアを実装できます。

SMPシステム用に記述されていないコードをSMPシステム上で実行する場合は、必要に応じてロックを使用するように変更し、共有データが更新されるクリティカル・セクションを保護したり、カーネル・プリエンプションから保護する必要があります。 ロック用のメソッドもプラットフォーム間で異なる場合があり、どのような状況で特定のタイプのロックをドライバ・メソッドとヘルパー・ルーチンで使用できるか(または使用すべきか)に関する制約も異なることがあります。

ページ構造体をカーネル・アドレス空間にマップ/マップ解除するときは、kmap()関数とkunmap()関数を使用して、システムでハイ・メモリーが永久的にマップされないようにする必要があります。

アーキテクチャ固有のコードがドライバ全体に散在している場合があります。 移植可能なコードを移植不可能なコードから分離すると、移植に関する問題の低減に役立ちます。