Linux Kernel 2.6 Documentation:

filesystems/xip.txt

• 原著作者: unknown
• 翻訳者: Seiji Kaneko < skaneko at mbn dot or dot jp >
• バージョン: 2.6.29
• 翻訳日時: 2009/06/03

=========================================================
これは、
linux-2.6.29/Documentation/filesystems/xip.txt の和訳
です。
翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
更新日 ： 2009/06/03
翻訳者 ： Seiji Kaneko < skaneko at mbn dot or dot jp >
校正者 ： Noguchi Kenji < tokyo246 at gmail dot com >
=========================================================			#Execute-in-place for file mappings
#----------------------------------
ファイルマップのための Execute-in-place
-------------------------------------

#Motivation
#----------
動機付け
--------
#File mappings are performed by mapping page cache pages to userspace. In
#addition, read&write type file operations also transfer data from/to the page
#cache.
ファイルマッピングは、ページキャッシュページをユーザ空間にマップすることで
実現されています。また、読み書きのようなファイル操作も、ページキャッシュと
の間でデータをやりとりしています。

#For memory backed storage devices that use the block device interface, the page
#cache pages are in fact copies of the original storage. Various approaches
#exist to work around the need for an extra copy. The ramdisk driver for example
#does read the data into the page cache, keeps a reference, and discards the
#original data behind later on.
ブロックデバイスインターフェースを持つ、メモリ技術を用いたストレージデバイ
スの場合、ページキャッシュページは実際には元のストレージのコピーになります。
このような追加コピーを削減するための様々な手法が存在します。例えば ramdisk 
ドライバは、ページキャッシュにデータを読み込み、その参照を保持し、裏にある
オリジナルデータをその後に削除します。

#Execute-in-place solves this issue the other way around: instead of keeping
#data in the page cache, the need to have a page cache copy is eliminated
#completely. With execute-in-place, read&write type operations are performed
#directly from/to the memory backed storage device. For file mappings, the
#storage device itself is mapped directly into userspace.
Execute-in-place はこの問題を全く別の方法で解決します。ページキャッシュに
データを保持するのではなく、ページキャッシュにコピーを持つ必要性を完全にな
くします。execute-in-place を使った場合、読み書き操作はメモリ技術を使った
ストレージデバイスとの間で直接やりとりされます。ファイルマッピングについて
は、ストレージデバイス自体がユーザ空間に直接マップされます。

#This implementation was initially written for shared memory segments between
#different virtual machines on s390 hardware to allow multiple machines to
#share the same binaries and libraries.
この実装は、もともとは S390 ハードウェア上で、別々の仮想マシン間でメモリセ
グメントを共有して、複数のマシンが同じバイナリとライブラリを共有できるよう
にするために書かれたものでした。

#Implementation
#--------------
実装
----
#Execute-in-place is implemented in three steps: block device operation,
#address space operation, and file operations.
Execute-in-place は三つのステップで実装されています。ブロックデバイス操作
と、アドレス空間操作と、ファイル操作です。

#A block device operation named direct_access is used to retrieve a
#reference (pointer) to a block on-disk. The reference is supposed to be
#cpu-addressable, physical address and remain valid until the release operation
#is performed. A struct block_device reference is used to address the device,
#and a sector_t argument is used to identify the individual block. As an
#alternative, memory technology devices can be used for this.
direct_access と言う名称のブロックデバイス操作が、ディスク上のブロックに
対する参照 (ポインタ) を解決するために用いられます。この参照は CPU からア
ドレス可能な物理アドレスで、リリース操作実行まではずっと有効であることを
想定しています。block_device 構造体への参照がデバイスを指定する際に用いら
れ、sector_t 引数が個々のブロックを識別するために用いられます。代替手段と
して、メモリ技術を用いたデバイスをこのように用いることができます。

#The block device operation is optional, these block devices support it as of
#today:
ブロックデバイス操作はオプションであり、現時点でブロックデバイス操作がサ
ポートされているのは以下のものです。
#- dcssblk: s390 dcss block device driver
- dcssblk: s390 dcss ブロックデバイスドライバ

#An address space operation named get_xip_mem is used to retrieve references
#to a page frame number and a kernel address. To obtain these values a reference
#to an address_space is provided. This function assigns values to the kmem and
#pfn parameters. The third argument indicates whether the function should allocate
#blocks if needed.
アドレス空間操作 get_xip_mem が、ページフレーム番号とカーネルアドレスへ
の参照を解決するために用いられます。これらの値を取得するために、アドレス
空間に対する参照が提供されます。この関数が、kmem と pfn パラメータに対す
る値を設定します。三番目の引数は、関数が必要に応じてブロックの割付を行な
うべきかどうかを示すものです。

#This address space operation is mutually exclusive with readpage&writepage that
#do page cache read/write operations.
#The following filesystems support it as of today:
#- ext2: the second extended filesystem, see Documentation/filesystems/ext2.txt
このアドレス空間操作は、ページキャッシュ読み書き動作を行なう readpage お
よびwritepage 操作と相互に排他です。現時点で以下のファイルシステムがこの
機能をサポートしています。

- ext2: 二番目の拡張ファイルシステム。Documentation/filesystems/ext2.txt 
  参照

#A set of file operations that do utilize get_xip_page can be found in
#mm/filemap_xip.c . The following file operation implementations are provided:
#- aio_read/aio_write
#- readv/writev
#- sendfile
get_xip_page を用いるファイル操作群が、mm/filemap_xip.c に記載されています。
以下のファイル操作実装が提供されています。
- aio_read/aio_write
- readv/writev
- sendfile

#The generic file operations do_sync_read/do_sync_write can be used to implement
#classic synchronous IO calls.
汎用ファイル操作 do_sync_read/do_sync_write を、従来の同期 IO コールを実装
するために使うことができます。

#Shortcomings
#------------
欠点
----
#This implementation is limited to storage devices that are cpu addressable at
#all times (no highmem or such). It works well on rom/ram, but enhancements are
#needed to make it work with flash in read+write mode.
#Putting the Linux kernel and/or its modules on a xip filesystem does not mean
#they are not copied.
この実装は、ストレージデバイスが CPU から常にアドレス付け可能 (highmem など
を用いない) でなければならないという制約を持ちます。rom/ram との組み合わせ
では上手く動きますが、flash を read+write モードで動作させるためには拡張が
必要です。Linux カーネルや、モジュールを xip ファイルシステム上に置くことは、
それらがコピーされないと言うことを意味するわけではありません。

Linux カーネル 2.6 付属文書一覧へ戻る