16 ビット UID から 32 ビット UID への変更に関するメモ - ユーザ空間とカーネル空間とのあいだで ioctl またはデータ構造をやりとり するときには、カーネルコードでは __kernel_uid_t と __kernel_uid32_t を 考慮しなければなりません。 - カーネル内部の構造体とコードでは、uid_t と gid_t を使用します。 32 ビットユーザ ID に移行するために、全ての Linux アーキテクチャでおこなう べき残りの作業は、次のとおりです。 - ディスククォータには、UID/GID の最大値とは関係のない、面白い制限があり ます。ファイルシステムの最大ファイルサイズによって制限されるのです。 というのも、クォータのレコードは、当該 UID に対応するオフセットに書か れるからです。クォータシステムが大きな UID を適切に扱えるかどうかに ついては、さらに調査が必要です。全てのアーキテクチャにおいて 64 ビット のファイルオフセットを扱えるのであれば、このことは問題とはならないで しょう。 - システム・アカウンティング・ファイルとの後方互換性を維持するかしないか、 つまりコメントが言うように後方互換性を切り捨てるべきか、を決める (現在、 旧 16 ビット UID と GID は、依然としてディスクに書き込まれており、以前 パディングスペースだった場所は、独立の 32 ビット UID と GID を格納する のに使われています)。 - エミュレートされる OS が 16 ビット UID を使用していた場合、OS エミュ レーションが 16 ビット UID 互換のシステムコールを呼び出しているのか、 それとも、そうでない場合、32 ビット UID システムコールを適切に使用して いるのか、を確認する必要がある。 これは少なくとも次のものに影響があります。 SunOS エミュレーション Solaris エミュレーション Intel の iBCS sparc64 での sparc32 エミュレーション (sparc32 に加えられた、新しい 32 ビット UID システムコール全てを サポートする必要があります) - 全てのファイルシステムが適切に動作することを確認する。 現在のところ、32 ビット UID は次のファイルシステムに対しては動くはずです。 ext2 ufs isofs nfs coda udf 次のファイルシステムに対する ioctl() の修正はできています。 ncpfs smbfs 次のファイルシステムには、16 ビット UID のラップアラウンドを防止する 簡単な修正が施されています。 minix sysv qnx4 他のファイルシステムは、まだチェックしていません。 - ncpfs ファイルシステムと smpfs ファイルシステムは、現在のところ、全ての ioctl() において 32 ビット UID を使用できません。32 ビット UID を取る 新しい ioctl() が幾つか追加されましたが、もっと必要です (ユーザ空間と カーネル空間とのあいだでやりとりされる新しいデータ構造体を取るものも 必要です)。 - ELF コアダンプ・フォーマットは、arm, i386, m68k, sh, sparc32 での 16 ビット UID しかサポートしていません。これを修正するのは、おそらく重要な ことではありませんが、やるとしたら、新しい ELF セクションを追加する必要 があるでしょう。 - カーネル内 NFS サーバをコントロールするのに使われる ioctl() は、arm, i386, m68k, sh, sparc32 では 16 ビット UID しかサポートしません。 - AX25 ネットワークの UID マッピング機能が適切に動作することを確認する (ユーザ空間とカーネル空間とのあいだのやりとりで、常に 32 ビット整数が 使われているので、安全なはずです)。 Chris Wing wingc@umich.edu 最終更新日： 2000 年 1 月 11 日 ------------------------------------------------------------ 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > 翻訳日： 2004/05/17 翻訳者： 川崎 貴彦 校正： IKEDA Katsumi 校正： Seiji Kaneko