=========================================================
ϡ
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 ե륷ƥ֤Ȥϡ
餬ԡʤȸȤ̣櫓ǤϤޤ
