[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[plamo:20385] Re: OS-Versionとプログラムの互換性
-
From:KOJIMA Mitsuhiro
-
Date:Mon, 25 Aug 2003 17:06:20 +0900 (JST)
- Subject: [plamo:20385] Re: OS-Versionとプログラムの互換性
- From: KOJIMA Mitsuhiro <kojima@xxxxxxxxxxx>
- Date: Mon, 25 Aug 2003 17:06:21 +0900 (JST)
こじま@私自身はプログラマじゃないので間違ったことを言ってたら訂正よろ
しく,です.
From: "H.Shiozaki" <sios_hs@yahoo.co.jp>
Subject: [plamo:20383] Re: OS-Versionとプログラムの互換性
Date: Mon, 25 Aug 2003 15:47:30 +0900
> 残った疑問(1)は,
> libcのLinuxシステムにおける階層的な位置付けです。
> 一般的な階層を,
> [1] [(layer) user space: application program]
> [2] [(layer) kernel space: kernel, kernel_module] (irq processを含む)
> [3] [(layer) hardware ]
> としたときに Libcは,[1],と[2] のどちらに位置付けられるのでしょうか?
[1] でせう.UNIX 系 OS の場合,カーネルスペース(カーネルモード)はカー
ネルにしか許されていない領域で,libc 自身も含めて libc 等を経由したユー
ザプロセス(shell も含む)には触れることはできません.
# 厳密に言うと ioperm() みたいなシステムコールがあるので,ちょっと微妙
# なところもあるが > Linux
> −−−
> 残った疑問(2)
> userアプリケーションでlibcを使った場合には,
> 例えば,atoi() の様な場合には,libcだけで処理が閉じていると思われますが,
> fopen() calloc() 等の場合には,kernelに処理を依頼するように思われ,
> libcのバージョンとカーネルのバージョンの対応関係には限界があるように
> 思われるのです。
> どの様な方法で,対処しているのでしょうか?
実際の内部処理は実装依存になりますが,fopen() や calloc() がどういう機
能を提供するかという仕様は POSIX 等で定義されており,カーネルも libc
もその定義に従うように作成されているので問題は起きないようになっています.
---------
こじま
- Follow-Ups
-
- [plamo:20389] Re: OS-Versionとプログラムの互換性, KOJIMA Mitsuhiro
- References
-
- [plamo:20244] Re: OS-Versionとプログラムの互換性, H.Shiozaki
- [plamo:20251] Re: OS-Versionとプログラムの互換性, KOJIMA Mitsuhiro
- [plamo:20383] Re: OS-Versionとプログラムの互換性, H.Shiozaki
[検索ページ]
[メール一覧]
Plamo ML 公開システム