x86とx86_64のLinuxシステムコール番号が異なるのはなぜですか？

システムコールインターフェイスは低レベルで実装されているため、「ジェネリック」コードではなく、アーキテクチャ/プラットフォームに依存します。

しかし、Linux 32ビットx86カーネルのシステムコールに、同様のアーキテクチャのLinux 64ビットx86_64で同じ値が保持されない理由がはっきりとわかりません。この決定の背後にある動機/理由は何ですか？

私の最初の推測は、バックグラウンド化の理由が32ビットアプリケーションをx86_64システム上で実行可能な状態に維持することであったため、システムコール番号への妥当なオフセットを介して、システムはユーザースペースが32ビットまたは64ビットであることを認識しますそれぞれ。ただし、そうではありません。少なくとも、x86_64のシステムコール番号0であるread（）は、この考えと一致しないように思われます。

もう1つの推測は、システムコール番号の変更にはセキュリティ/強化の背景があるかもしれないということです。

アーキテクチャに依存するコード部分の実装の課題に無知であるため、システムコール番号を変更する必要はないように思われます（16ビットのレジスタでさえ、すべてを表すために現在〜346の数値よりも多くを格納するため）呼び出し）、互換性を破る以外の何かを達成するのに役立ちます（ただし、ライブラリlibcを介してシステムコールを使用すると、軽減されます）。

特定の番号付けの背後にある理由については、他のどのアーキテクチャとも一致しません（x86_64アーキテクチャのほんの一部である「x32」を除く）：Linuxカーネルでのx86_64サポートのごく初期には、深刻な後方互換性の制約により、すべてのシステムコールは、キャッシュラインの使用レベルで最適化するために番号が付け直されました。

これらの選択の具体的な根拠を知るほどカーネル開発について十分な知識はありませんが、明らかに、既存のアーキテクチャからリストをコピーして未使用のものを削除するのではなく、これらの特定の番号ですべての番号を付け直すという選択肢の背後にあるロジックがあるようです。順序は、それらが呼び出される頻度に基づいているようです。exitとforkは「基本的」に見えるかもしれませんが、プロセスごとに1回だけ呼び出されます。

同じキャッシュライン内で一緒に使用される一般的なシステムコールを保持することについて何かが起こっているかもしれません（これらの値は単なる整数ですが、それぞれに関数ポインタを持つカーネル内のテーブルがあるため、8つのシステムコールの各グループが占有しますそのテーブルの64バイトのキャッシュライン）

「amd64 linuxでシステムコール番号が異なるのはなぜですか」という質問に対する回答をご覧ください。スタックオーバーフロー。

まとめると、互換性のために、システムコールリストは安定しており、成長しかできません。x86 64アーキテクチャが登場したとき、ABI（引数の受け渡し、戻り値）が異なっていたため、カーネル開発者は長い間待ち望まれていた変更をもたらす機会を得ました。

一言で言えば、誰かが「N+1それを行うことの不当に互換性のない方法はN方法よりも優れている」と考えたからです。歴史的なアーチの場合、syscall番号は通常、いくつかのレガシーな独自のUNIXに一致するように選択されました。しかし、x86_64の場合、カーネル開発者は好きな番号を自由に選択できました。単純な選択を行って既存の番号を再利用するのではなく、彼らは新しい標準を発明することを選択しました。その後、彼らはaarch64と他の多くのためにそれを再びしました。これは、Linuxカーネル開発で頻繁に繰り返されるパターンです。