JP5891963B2 - アドレス管理装置、及びプログラム - Google Patents

Description

本発明は、アドレス管理装置、及びプログラムに関する。

メモリ管理ユニットを有するマイクロプロセッサシステムにおいて、メモリ管理ユニット制御プログラムを物理アドレスと論理アドレスの両方にマッピングをかけた仮想空間を用いて一旦別の仮想アドレスに待避することにより、自由な仮想空間を生成するメモリ制御方式が知られている（例えば、特許文献１参照）。

ＣＰＵ等の実メモリの物理空間とジョブ処理上設定した仮想メモリの論理空間とを対応させてアドレスマッピングする方式において、前記論理空間に追随される共用メモリの補助論理空間を配設し、この共用メモリ内のアドレスを前記物理空間内のアドレスと同一に設定したマッピング方式も知られている（例えば、特許文献２参照）。

画像形成処理を行うアプリケーションのプロセスと、画像形成処理で利用されるハードウェア資源の管理を行うコントロールサービスのプロセスとにメモリをマップする画像形成装置であって、前記メモリ上に、前記プロセスによって直接マップ可能な直接マップ領域を少なくとも獲得する領域獲得手段と、前記直接マップ領域の物理アドレスと、仮想メモリ領域上に含まれる直接マップ領域用の仮想アドレスとを対応付けたアドレス変換手段とを有することを特徴とする画像形成装置も知られている（例えば、特許文献３参照）。

更に又、オペレーティングシステムが管理するメインメモリの管理領域が所定領域に制限されているコンピュータシステムにおいて、前記メインメモリの前記所定領域以外の領域である管理外領域を利用可能にするためのコンピュータプログラムであって、前記オペレーティングシステムが管理するメモリ領域を前記管理外領域にまで拡張する物理アドレス拡張モードを有効にする設定を行う設定機能と、前記物理アドレス拡張モードを有効にする設定がなされているときに、前記メインメモリの前記管理外領域を、仮想アドレス空間にマッピングするマッピング機能と、をコンピュータに実現させるためのコンピュータプログラムも知られている（例えば、特許文献４参照）。

特開昭６４−８２１５１号公報 特開平３−２１８５４４号公報 特開２００３−３１６６４６号公報 特開２０１０−４４５０３号公報

本発明は、あるオペレーティングシステム上で動作させるために作成されたプログラムを、他のオペレーティングシステム上で動作させるための移植作業を容易にすることができるアドレス管理装置、及びプログラムを得ることを目的とする。

請求項１の発明のアドレス管理装置は、第１オペレーティングシステム上で動作させるために作成されたプログラムに固定値で指定されたアドレス値の範囲を取得する取得手段と、前記取得したアドレス値の範囲と、第２オペレーティングシステムの仮想アドレス空間上で前記プログラムを実行させるときに使用される実行時仮想アドレスの範囲と、が重複しないように、前記実行時仮想アドレスの前記仮想アドレス空間上における配置を変更する変更手段と、前記取得した範囲のアドレス値が前記第２オペレーティングシステムの仮想アドレス空間上の仮想アドレスとして用いられるように、前記仮想アドレス空間上の仮想アドレスと、前記第２オペレーティングシステムが管理する物理アドレス空間の物理アドレスと、を対応付けるテーブルを設定する設定手段と、を備えている。

請求項２の発明は、請求項１に記載のアドレス管理装置において、前記変更手段は、予め定められた配置単位毎に、前記実行時仮想アドレスの配置を変更する。

請求項３の発明は、請求項２に記載のアドレス管理装置において、前記変更手段は、前記配置単位を、前記取得したアドレス値の範囲のサイズに応じて決定する。

請求項４の発明は、請求項２又は請求項３に記載のアドレス管理装置において、前記変更手段は、前記実行時仮想アドレスの配置の変更が失敗した場合には、該配置の変更が失敗したときに用いた配置単位よりも小さな配置単位で、前記実行時仮想アドレスの配置を変更する。

請求項５の発明は、請求項１〜請求項４の何れか１項記載のアドレス管理装置において、前記変更手段は、前記取得した範囲が、前記実行時仮想アドレスの作業用領域又はスタック領域に重畳する場合には、前記実行時仮想アドレスの前記重畳する範囲を減少させて、前記実行時仮想アドレスの配置を変更する。

請求項６の発明は、コンピュータを、第１オペレーティングシステム上で動作させるために作成されたプログラムに固定値で指定されたアドレス値の範囲を取得する取得手段、前記取得したアドレス値の範囲と、第２オペレーティングシステムの仮想アドレス空間上で前記プログラムを実行させるときに使用される実行時仮想アドレスの範囲と、が重複しないように、前記実行時仮想アドレスの前記仮想アドレス空間上における配置を変更する変更手段、及び前記取得した範囲のアドレス値が前記第２オペレーティングシステムの仮想アドレス空間上の仮想アドレスとして用いられるように、前記仮想アドレス空間上の仮想アドレスと、前記第２オペレーティングシステムが管理する物理アドレス空間の物理アドレスと、を対応付けるテーブルを設定する設定手段、として機能させるためのプログラムである。

請求項１に記載の発明によれば、あるオペレーティングシステム上で動作させるために作成されたプログラムを、他のオペレーティングシステム上で動作させるための移植作業を容易にすることができる。

請求項２に記載の発明によれば、本構成を有しない場合に比べて、実行時仮想アドレスの配置を効率的に変更できる。

請求項３に記載の発明によれば、本構成を有しない場合に比べて、実行時仮想アドレスの配置の失敗を抑制できる。

請求項４に記載の発明によれば、本構成を有しない場合に比べて、配置が失敗した後に実行される配置の成功率を向上させることができる。

請求項５に記載の発明によれば、本構成を有しない場合に比べて、実行時仮想アドレスの配置を効率的に変更できる。

請求項６に記載の発明によれば、あるオペレーティングシステム上で動作させるために作成されたプログラムを、他のオペレーティングシステム上で動作させるための移植作業を容易にすることができる。

実施形態に係る画像形成装置の概略構成を示すブロック図である。 画像形成装置に実装されたアドレス管理装置の機能構成を示す図である。 本実施形態のアドレス管理装置により行なわれる処理の流れを示すフローチャートである。 アドレス空間の配置を模式的に示した図である。 移植対象プログラム及び拡張モジュールのリンクを実行するリンカを用いて、実行時仮想アドレスの配置変更を実現する例を説明する模式図である。

以下、図面を参照して、実施形態について詳細に説明する。

図１は、実施形態に係る画像形成装置１０の概略構成を示すブロック図である。画像形成装置１０は、ＣＰＵ（Central Processing Unit）１２、ＲＡＭ（Random Access Memory）１４、例えばフラッシュメモリ等からなる不揮発性の記憶部１６、Ｉ／Ｏ（入出力）ポート１８、通信インタフェース２０を備え、それらはバス２２を介して相互に接続されている。

ＩＯポート１８には、ＬＣＤ等から成る表示部及びテンキーやタッチパネル等から成り利用者による操作を受付ける操作受付部が設けられた操作パネル２４、ＨＤＤ（ハードディスクドライブ）２６、及び入力された画像データが表す画像を記録媒体上に形成する画像形成部２８が接続されている。

また、通信インタフェース２０は、通信回線やＬＡＮ等のネットワークに接続されている。画像形成装置１０は、通信インタフェース２０を介して、該ネットワークに接続された他の端末と相互に情報をやりとりする。

ＣＰＵ１２は、記憶部１６に記憶されたプログラムを実行する。なお、ＣＰＵ１２が実行するプログラムが記憶される記録媒体は、記憶部１６に限定されず、例えば、ＨＤＤ２６であってもよいし、ＣＤ−ＲＯＭであってもよいし、図示は省略するが、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの可搬型記録媒体や画像形成装置１０の外部に備えられたＨＤＤ等の記憶装置等であってもよく、更にまたネットワークを介して接続されたデータベース、或いは他のコンピュータシステム並びにそのデータベースであってもよい。また、ＲＡＭ１４は、プログラム実行時のワークメモリ等として利用される。

記憶部１６には、画像形成装置１０の利用者に対して画像形成装置１０の様々な機能を提供する処理を行うアプリケーションのプログラムと、アプリケーションのプログラムを実行するためのプラットフォームとして機能するオペレーティングシステム(ＯＳ)のプログラムが各々記憶されている。このＯＳは、仮想アドレス機構が導入され、仮想アドレスを使用するＯＳであって、例えば、Linux（登録商標）であってもよい。

更に又、記憶部１６には、あるＯＳ上で動作させるために作成されたプログラムを、他のＯＳ上で動作するように実装する（以下、移植という）ために事前に作成された拡張モジュールのプログラムも記憶されている。本実施形態では、移植元のＯＳ（上記「あるＯＳ」に相当）が、仮想アドレスを使用しない（仮想アドレス機構を有さない）リアルタイムＯＳであり、移植先のＯＳ（上記「他のＯＳ」に相当）が、上記仮想アドレスを使用するＯＳである場合を例に挙げて説明する。

なお、拡張モジュールは、事前に移植対象プログラムとリンクされた状態で、記憶部１６に記憶されている。本実施形態では、拡張モジュールと移植対象プログラムとがリンクされて生成されたモジュールを、ロードモジュールと称する。本実施形態では、ロードモジュールに含まれる拡張モジュールとＯＳの機能とを用いて、移植対象プログラム自体を変更することなく、移植前の仮想アドレスを使用しない動作環境から、仮想アドレスを使用する動作環境に移植させるようにしている。

ここで、プログラムの移植に係る背景について、より詳細に説明する。組込ソフトウェアの高機能化に伴い、Linux（登録商標）などの高機能なＯＳを用いて組込ソフトウェアを開発する必要が生じている。既存の組込ソフトウェアは既に大規模化しており、既存ソフトウェアと同等の機能を高機能なＯＳに対応するように新規に開発することは困難である。従って、既存のソフトウェアを、高機能なＯＳ上に移植する必要性がある。

従来の組込ソフトウェアは、仮想アドレスを使用しない（仮想アドレス機構を有さない）リアルタイムＯＳ上で動作するように実装され、アドレス値を用いてメモリやＩＯポート等のハードウェア資源（以下、リソースという）を直接アクセスするように実装されている場合が多い。即ち、リソースを指定するためのアドレス値を固定したプログラミングをしているソフトウェアが多く存在していた。ここでアドレス値を固定したプログラミングとは、アドレス値を数値等の固定値で記述したり、アドレス値を固定値で記述した領域への参照を使用するなど、直接または間接的に固定したアドレスを利用したプログラミングである。リアルタイムＯＳでは、アドレス値を直接的に物理アドレスと対応させて使用するため、メモリやＩＯポート等のリソースを、プログラムコードに含まれるアドレス値を用いて直接アクセスすることが可能であるためである。

一方、高機能ＯＳには、仮想アドレスを使用するためのメモリ管理機構が導入され、プログラムはユーザプロセス毎に独立したメモリ空間で、仮想アドレスを用いて動作する。従って、プログラムがアドレス値を用いてアクセスした場合、仮想アドレスでのアクセスとして扱われる。ＯＳは、その仮想アドレスを物理アドレスに対応付ける変換表（ページテーブル）を事前に設定しておく（以降、この設定をマップと称する）。ＣＰＵは、ページテーブルに基づいて仮想アドレスを物理アドレスに変換することで、メモリやＩＯポートにアクセスする。ページテーブルは、ＲＡＭ１４や記憶部１６に記憶される。

物理アドレスを、利用可能な（即ち使用済でない）仮想アドレスにマップする機能として、例えば、Linux（登録商標）などUnix（登録商標）系のＯＳでは、mmap()システムコールというマップ機能（関数）が用意されている。一般的には、このマップ機能によりＯＳが用意した仮想アドレスが使用される。このため、従来の環境下で直接的に物理アドレスに対応するものとして固定値のアドレス値が実装されたプログラムを実行したとしても、そのアドレス値をそのまま用いてリソースにアクセスすることはできない。

更に、プログラムに実装されたアドレス値が任意の仮想アドレスに割り当てられるように上記マップ機能を拡張したとしても、割り当てられたアドレスが、プログラムの実行時に使用される仮想アドレスの領域、例えば、プログラムのコード、データ、及び一時データが展開される領域や、マップ機能で割当済の領域、スタックなどに割り当てられた領域等と重複してしまう可能性がある。

そこで、仮想アドレスを使用しないＯＳ上で動作するように作成されたプログラムを、仮想アドレスを使用するＯＳ上で動作させるためには、そのプログラムに固定値で指定されたアドレス値を、利用可能な（プログラム実行時に使用されない）仮想アドレスとなるようにソースコードを変更する手法が考えられる。

しかしながら、そのようなプログラムは、その実装も古く規模も大きく複雑である場合も多く、プログラム中に分散する多くの依存箇所（アドレス値）を特定し、ソースコードを変更することは困難である。例えば、画像メモリに依存した画像ライブラリなどの場合、アドレス値に依存するコード量が多く、ソースコードの変更が困難となる。

そこで、ソースコードに分散するアドレス値の各々を変更しなくても、仮想アドレスを使用するＯＳ上で動作可能となるように、本実施形態の画像形成装置１０に、以下に説明するアドレス管理装置を実装した。ここで、アドレス管理装置は、画像形成装置１０のＣＰＵ１２が記憶部１６に記憶されたプログラム（ここでは、移植対象プログラム本体を除く）実行することにより実現される機能により構成される。

図２は、画像形成装置１０に実装されたアドレス管理装置の機能構成を示す図である。

＜ロードモジュール＞

ロードモジュール５０は、前述したように、移植対象プログラム５２と拡張モジュール５４とがリンクされたモジュールである。拡張モジュール５４は、移植する際に、移植対象プログラム５２に対して追加的に付与されたプログラムであるため、移植対象プログラム５２及び拡張モジュール５４は、ロードモジュール５０として一体的に扱われるが、拡張モジュール５４は移植対象プログラム５２をＯＳ３２上で正常に動作させるために使用されるモジュールであって、移植対象プログラムとは実行開始タイミング等も異なることから、以下では移植対象プログラム本体としての移植対象プログラム５２と、追加的な拡張モジュール５４とを区別して説明する。

移植対象プログラム５２には、リソース（ＲＡＭ１４等のメモリやＩＯポート１８等）をアクセスするための（すなわち、リソースを指定するための）アドレス値が、移植元の物理空間の物理アドレス値に依存して記述されている依存部分と、該アドレス値が上記物理アドレス値に依存せずに記述されている非依存部分とがある。より具体的には、前者の場合には、リソースを指定するためのアドレス値が即値で（前述したように、数字等の固定値で直接的或いは間接的に）プログラムコードに記述されている。後者の場合には、該アドレス値が固定値を記述しない形式でプログラムコードに記述されており、例えば、プログラムをコンパイルする際などにアドレスが解決される（すなわち、アドレス値は可変）。以下、前者の、物理アドレス値に依存して固定値がプログラムに記述されたアドレス値を依存アドレス値と呼称し、後者の非依存アドレス値と区別して説明する。

拡張モジュール５４は、移植対象プログラム５２の補助的な機能を有し、移植対象プログラム５２の情報を提供するプログラムである。拡張モジュール５４は、以下の３つの機能を有する。

(1)移植対象プログラムに含まれる依存アドレス値の範囲を示す情報を保持する。後述するローダ３８がこの値を参照し、この値の範囲が、移植対象プログラム５２を含むロードモジュール５０の実行時の仮想アドレスの領域と重畳しているか否かを判断する際に使用する。

(2)リソースの物理アドレスを取得する。拡張モジュール５４は、移植先環境でのリソースの物理アドレスを、デバイスドライバ３６を介して参照する。

(3)取得したリソースの物理アドレスを、(1)の依存アドレスが仮想アドレスとなるようにマップする（ページテーブルを設定する）。マップ処理は、デバイスドライバ３６を介して実行される。

なお、拡張モジュール５４を設ける代わりに、移植対象プログラム５２を変更し、拡張モジュール５４の機能及び拡張モジュール５４が保持する情報を、移植対象プログラム５２に保持させてもよい。このように移植対象プログラム５２を変更する場合には、拡張モジュール５４なしで、ロードモジュールが構成される。なお、このように移植対象プログラム５２を変更したとしても、拡張モジュール５４のコードを移植対象プログラム５２のコードに追加するだけであるため、拡張モジュール５４を移植対象プログラム５２にリンクさせる場合と同様の作業は発生するものの、移植対象プログラム５２のコードに分散された依存アドレス値を変更するほどの手間はかからない。

＜移植先環境＞

図２において、移植先環境３０が、仮想アドレスを使用するＯＳ３２と、当該ＯＳ３２が物理空間として管理するハードウェア４０とで表わされている。また、図２では、画像形成装置１０に装備された様々なハードウェアを総称して、「ハードウェア４０」として図示した。ＯＳ３２は、カーネル３４、デバイスドライバ３６、及びローダ３８を含んで構成される。

デバイスドライバ３６は、ＯＳ３２の機能の１つとして動作する。本実施形態では、デバイスドライバ３６は、以下の３つの機能を有する。

(1)物理アドレス空間に、移植対象プログラム５２が利用するリソースを割り当てる。具体的には、ハードウェア４０のレジスタアドレスを割り当てる処理を行う。これは、カーネル３４に対してレジスタアドレスを登録することにより行なわれる。

(2)割り当てたリソースの物理アドレスを、拡張モジュール５４に提供する。

(3)拡張モジュール５４からのマップ要求に応じて、仮想アドレスをマップする。即ち、移植対象プログラム５２の依存アドレスが仮想アドレスとして扱われるように、割り当てた物理アドレスと依存アドレスとが対応付けられたページテーブルを設定する。この設定処理の一部を、ＯＳ３２の元々の機能として備わっていた機構の一部を利用することにより実行してもよい。また、機能や使用するリソース毎に、別々のデバイスドライバで実現しても良い。更に又、他のデバイスドライバ、又は他のＯＳが提供するマップ機構を用いて仮想アドレスを割り当てても良い。

なお、拡張モジュール５４とデバイスドライバ３６との機能分担は変更可能である。例えば、拡張モジュール５４が物理アドレスを参照し、拡張モジュール５４が、依存アドレスが仮想アドレスとして扱われるようにデバイスドライバ３６に指示し、デバイスドライバ３６が事前に割り当てた物理アドレスを当該指示された仮想アドレスにマップするようにしても良い。

ローダ３８は、ＯＳ３２の機能の１つとして動作する。画像形成部２８は、ロードモジュール５０を仮想空間上にロードして実行する。ここでは、ローダ３８は、ＯＳ３２の仮想空間のメモリ上に、ロードモジュール５０を実行するときに使用される仮想アドレス（以下、実行時仮想アドレスという）の領域を設定する。実行時仮想アドレスの領域には、例えば、ＯＳ３２をLinux（登録商標）とした場合、テキスト（text）領域、初期値ありデータ（data）領域、初期値なしデータ（bss）領域、ヒープ（heap）領域、ダイナミックリンクライブラリ（mmap）領域、及びユーザスタック（user stack）領域が含まれる。ローダ３８は、これら領域を設定して配置する。text領域には、プログラムの命令列が展開される。data領域には初期値付きの変数が展開される。bss領域には、初期値なしの変数が展開される。heap領域及びmmap領域は、作業用メモリ領域であって、何れもmalloc()ラッパ関数で作業用メモリとして割り当てられる領域である。また、mmap領域は、mmap()システムコールにおいてファイルや物理メモリにマップされる領域である。user stack領域は、一時的に待避させるデータ等が格納される。なお、text領域、data領域、bss領域は、連続した領域として配置されるものとして規定されることから、以下では、text領域、data領域、及びbss領域をまとめて、text/data/bss領域と称する。

なお、ローダ３８は、依存アドレスが、実行時仮想アドレス空間と重畳している場合、即ち、使用する(可能性がある)仮想アドレスに同一の部分が存在する場合、実行時仮想アドレス空間の配置を変更する。

次に、本実施形態の作用を図３、図４を参照して説明する。図３は、本実施形態のアドレス管理装置により行なわれる処理の流れを示すフローチャートである。なお、図２において、動作の主体と動作の作用対象とを矢印で結び、図３のステップ番号を図２の対応する矢印の近傍に付して、各ステップの動作の手段を明示した。また、図４は、アドレス空間の配置を模式的に示した図である。0x14000000〜0x1C000000に存在する128MBのビットマップメモリに対して、この範囲のアドレスを即値でアクセスして画像処理を実行するプログラムを移植対象プログラム５２として移植する場合において、text/data/bss領域の仮想アドレスと依存アドレス値とが重複する例が示されている。

図４（Ａ）は、移植元の物理アドレス空間で移植対象プログラム５２が使用するアドレス値（依存アドレス値）の範囲例を示す図であり、図４（Ｂ）の（１）及び（２）は、移植先の仮想アドレス空間の後述する実行時アドレス配置例を示し、図４（Ｂ）の（３）は、移植先における物理アドレス空間のリソースの物理アドレス値の範囲例を示す図である。

なお、ここでは、移植対象プログラム５２及び拡張モジュール５４は事前にコンパイルされ、ロードモジュール５０としてリンクされているものとする。リンクの方法は、再配置可能、すなわちロードの際に仮想アドレスを解決する方法と、ＯＳ３２で決められた仮想アドレスが静的に割り当てられる方法とがあるが、何れを採用してもよい。

図３のステップＳ０１において、デバイスドライバ３６は、物理アドレス空間に移植対象プログラム５２が利用するリソース（ＲＡＭ１４やＩＯポート１８など）を割り当てる（図４（Ｂ）の（３）も参照）。例えば、カーネル３４に登録することで、128MBの物理メモリのアドレス空間を割り当てる。なお、カーネル３４のブート処理により、ブートメモリとして割り当てても良いし、カーネル３４起動の際に、memパラメータを指定してカーネル３４が認識するメモリを搭載されているメモリよりも少なく設定し、カーネル３４が認識しないメモリ領域を使用するようにしても良い。

また、例えば、下記ステップＳ０２を先に行ない、下記ステップＳ０２で取得された依存アドレス値の範囲の前後にマージンを持たせたときのサイズに対応させてリソースを割り当てるようにしても良い。その際、アラインメントを考慮して割り当てるようにしても良い。例えば、ＯＳ３２は、物理アドレス空間及び仮想アドレス空間を、基本的に予め定められたサイズのページと呼ばれる単位に分割してメモリ管理を行うが、上記物理アドレス空間にリソースを割り当てる際、当該リソースの物理アドレス空間における開始アドレスが、ＯＳ３２のページメモリの単位(4K、2Mなど)の倍数になるようにする。

また、リソース割当の別の例として、ハードウェア４０のレジスタやビデオメモリなどの物理アドレスを取得し、カーネル３４に登録する場合などがある。

次に、ステップＳ０２において、ローダ３８は、移植対象プログラム５２が内部で使用している依存アドレス値の範囲を取得する（図４（Ａ）も参照）。この値は、予めロードモジュール５０の拡張モジュール５４内のコードの識別可能なセクション中に格納しておく。例えば、ELF形式のセクションヘッダにアドレス値とその範囲の情報を格納しておくことができる。ローダ３８は、当該セクションを読出すことで、依存アドレス値の範囲を取得する。なお、移植対象プログラム５２及び拡張モジュール５４を含むロードモジュール５０は、この時点では起動されていない。

このように、拡張モジュール５４に依存アドレス値の範囲を示す情報を保持させておき、移植対象プログラム５２とリンクしたロードモジュール５０として構成することで、移植対象プログラム５２本体は変更不要となる。依存アドレス値の範囲を示す情報としては、例えば、開始及び終了アドレスを格納するか、或いは開始アドレスとサイズ(バイト数)を格納する。

なお、依存アドレス値の範囲を示す情報を、拡張モジュール５４とは別に設定ファイルに記述して、記憶部１６等に記憶しておくなど、他の方法を用いても良い。

ステップＳ０３において、ローダ３８は、ロードモジュール５０の実行時仮想アドレス空間の情報を取得する（図４（Ｂ）の（１）も参照）。具体的には、ローダ３８は、ロードモジュール５０のオブジェクトファイルを解析し、ロードモジュール５０のプログラムのコード及びデータが記憶される領域（前述したtext/data/bss領域）の各領域や、heap領域、mmap領域、及びuser stack領域の各領域のサイズ（容量）を取得する。なお、各領域の仮想アドレス空間における開始アドレスは、ＯＳ３２に応じて予め規定値が定められているため、この値を取得する。また、各領域のサイズは、使用量が可変であるので、その最大値を各領域のサイズとして取得するものとする。

例えば、Linux（登録商標）のx86シリーズの32ビット版の場合の規定値では、text/data/bss、heap、mmap、及びuser stackの各領域の仮想アドレス空間上での開始アドレスは、各々、0x10000000、bss領域の直後、0x80000000、0xC0000000である。ここで、user stack領域は、開始アドレスから前方(アドレス値の小さい方向)に使用される。また、0xC0000000以降は、カーネル３４により利用される仮想アドレスの範囲とされる。

次に、ステップＳ０４において、ローダ３８は、依存アドレス値の範囲と、実行時仮想アドレスの範囲とで重複している部分があるか否かを判断する。例えば、依存アドレス値の範囲が0x14000000〜0x1C000000で、text/data/bss領域のサイズが512MBとすると、上記開始アドレスの規定値から、その仮想アドレスの範囲は、0x10000000〜0x30000000となるため、依存アドレス値の範囲は、text/data/bss領域に含まれることになる。この場合には、重複していると判断される（図４（Ａ）及び図４（Ｂ）の（１）も参照）。

ローダ３８は、依存アドレス値の範囲と、実行時仮想アドレスの範囲とで重複している部分があると判断した場合には（ステップＳ０５、Ｙｅｓ）、ステップＳ０６において、ローダ３８は、ロードモジュール５０の実行時仮想アドレスが、依存アドレス値の範囲と重複しないように、ロードモジュール５０の実行時仮想アドレスの配置を決定する。

この時、仮想アドレス空間を予め定められた単位に区切り、区切られた各セグメントのうち、依存アドレス値を含まないセグメントに、実行時仮想アドレスが配置されるように実行時仮想アドレスの各領域のアドレスを決定する。

ここで、各セグメントの単位は任意に設定可能である。図４（Ｂ）の（２）に、1GBを単位とし、先頭の1GBに依存アドレス値の範囲が存在するため、先頭の1GBには、ロードモジュール５０の実行時仮想アドレスの各領域を配置しないようにした例を示す。1バイト以上の任意の単位で重複が回避されるように配置処理することが可能である。

また、この処理は一般に箱詰め問題(bin packing problem)と呼ばれる分野のうち、1次元の箱詰め問題(One-dimensional bin packing problem)のアルゴリズムを応用することが可能である。

ステップＳ０７において、ローダ３８は、上記決定した配置に従って、ロードモジュール５０の実行時仮想アドレスを再配置する。静的にリンクされているロードモジュール５０の場合には、ステップＳ０６の決定結果に基づき、ロードモジュール５０のオブジェクトファイル中に埋め込まれている実行時仮想アドレスを変更する。元のロードモジュール５０のファイルを直接変更するのではなく、一時ファイルやメモリ上に読み出した状態で変更する。この処理は次のステップＳ０８で示したロードの処理中に、逐次的に実行するようにしても良い。

また、再配置可能にリンクされているロードモジュール５０の場合には、ロード時のアドレス解決の際に、ステップＳ０６の決定結果に基づき、アドレスを設定しながらロードしても良い。

ここで、変更/解決されるアドレスは、ロードモジュール５０に含まれる変数や関数のアドレスであり、変数に格納されたアドレスは対象にならない。リソースは、元々ロードモジュール５０の外部にあり、ポインタ変数内に、そのリソースのアドレスが事前に格納されるか、或いは実行の際に格納されるので、変更/解決の対象にはならない。

ステップＳ０８において、ローダ３８は、上記決定した実行時仮想アドレスの領域にロードモジュール５０をロードし、ロードモジュール５０中の拡張モジュール５４の実行を開始する。ここでは、まだ移植対象プログラム本体（移植対象プログラム５２）の実行は開始されない。

ローダ３８は、ロードモジュール５０のタスク管理テーブルを生成し、上記決定された実行時仮想アドレスの配置に従い、ページテーブルを設定することで、ロードモジュール５０の仮想アドレス空間を生成する。その他、引数、環境変数、ファイル管理、及びマウントポイント等、プログラムの実行に必要な種々の資源を割りあて、ＯＳ３２のスケジューラの実行キューに追加する。

ステップＳ０９において、拡張モジュール５４は、デバイスドライバ３６を呼び出して、ステップＳ０１で割り当てたリソースの物理アドレス及びサイズの情報を取得する。なお、ロードモジュール５０の起動パラメータや設定ファイルに当該リソースの物理アドレス及びサイズの情報を記述しておき、ロードモジュール５０から上記情報を取得するようにしても良い。

ステップＳ１０において、拡張モジュール５４は、デバイスドライバ３６を呼び出して、デバイスドライバ３６に、移植先におけるリソースの物理アドレスを、移植対象プログラム５２の依存アドレス値にマップさせる。デバイスドライバ３６は、拡張モジュール５４からの要求に応じて、依存アドレス値を仮想アドレスとして、リソースを参照するためのページテーブルを設定することにより、当該依存アドレス値をリソースの物理アドレスにマップする。

例えば、Linux（登録商標）等のUnix（登録商標）系のＯＳでは、mmap()システムコールが用意されているので、拡張モジュール５４が、これを利用可能である。mmap()システムコールは、以下のように表わされる。

void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);

ここで、第１引数には、割り当てたい仮想アドレス、即ち、プログラムの依存アドレスの範囲の先頭アドレスを指定する。第２引数には、依存アドレス値の範囲の長さを指定する。第６引数には、ステップＳ０１で割り当てた物理アドレスを指定する。第５引数には、後述するデバイスドライバ３６をオープンして得たファイル記述子を指定する。第３引数には、PROT_READ及びROT_WRITEのフラグを指定する。第４引数には、MAP_FIXEDを指定する。また、マップした領域をプロセス間で共有する場合は、MAP_SHAREDフラグを併せて指定しても良い。

ここで、デバイスドライバ３６には、mmap()システムコールに対応して呼び出されるmmapメソッドが用意されており、その中で、デバイスドライバ３６は、指定された仮想アドレスに対して、仮想アドレス機構で使用するページテーブルを設定する。また、ＯＳ３２で使用する他の管理情報も併せて設定する。ＯＳ３２がLinux（登録商標）の場合には、使用済の仮想アドレスの範囲を管理するvmarea構造体を設定する。また、ＯＳ３２が用意しているサービスルーチンを利用して、これらの処理を実行しても良い。ＯＳ３２がLinux（登録商標）の場合には、ＯＳ３２のサービス関数remap_pfn_range()が利用可能である。

ステップＳ１１において、拡張モジュール５４は、移植対象プログラム５２を呼び出して、移植対象プログラム５２の実行を開始する。

一方、ステップＳ０５において、重複する部分はないと判断された場合には、ステップＳ１２において、実行時仮想アドレスの配置はそのままとされ、ステップＳ０８に進み、上記説明した処理が行なわれる。

以上説明したように、本実施形態のアドレス管理装置によれば、移植元ハードウェアのリソース(メモリ、IOポート等)の物理アドレス値に依存して実装されたプログラムを、実装変更する（すなわち、移植対象プログラム本体のコードに記述されたアドレス値の各々を変更する）ことなしに、移植先仮想アドレス空間で実行することができる。

なお、前述したように、拡張モジュール５４を設ける代わりに、移植対象プログラム５２を変更し、拡張モジュール５４の機能及び拡張モジュール５４が保持する情報を、移植対象プログラム５２に保持させて移植させる場合には、移植対象プログラム５２の本体のプログラムではなく、上記拡張モジュール５４が行うステップは、移植対象プログラム５２の拡張モジュール５４の機能に相当する部分が担い、移植対象プログラム５２の本体部分の実行は、ステップＳ１１において開始される。

アドレス管理装置の構成及び作用は、上記説明した例に限定されない。以下、アドレス管理装置の様々な変形例について説明する。

（１）アラインメントの制御

ステップＳ０６で重複を回避する際に、アラインメントを考慮し依存アドレス値の範囲の前後に余裕を持たせた状態で再配置を決定してもよい。例えば、実際の依存アドレス値の範囲の開始又は終了が4Kバイトの倍数でなかった場合、各々、開始アドレスを前方に、終了アドレスを後方に拡大し、4Kバイトの倍数となるように扱っても良い。

（２）セグメントの細分化

前述したステップＳ０６において、1GB単位のセグメントに分割し、これを配置単位として重複を回避する例を示した。しかしながらこの場合、1GBの境界を跨ぐ領域に依存アドレス値の範囲が存在すると、全4Gバイトの仮想アドレス空間の場合、残り2セグメントとなり、text/data/bss領域、heap,mmap領域、user stack領域の複数の領域を残りの各セグメントに配置できなくなってしまう。これを回避するため、予めセグメントの単位（配置単位）を小さく設定しておくようにしてもよい。

また、依存アドレス値の範囲のサイズに応じて、配置単位を決定するようにしても良い。例えば、80MBを最小単位とし、2MBの倍数を単位として配置する場合において、依存アドレス値の範囲のサイズが200MBとすると、それより大きい256MBのセグメントサイズを１単位として再配置が決定されるようにする。

また、最初は、配置単位のサイズを大きく設定しておき、配置が失敗した場合には、配置単位を当該配置が失敗したときのサイズより小さなサイズとして、再配置を試みるようにしてもよい。それでも、なお配置が失敗した場合には、更に小さなサイズを配置単位おして再配置を試みる。例えば、配置単位を1GBから、２分の１ずつ徐々に小さくしていき、配置が成功するまで繰り返すようにしても良い。

（３）ロードモジュール実行時仮想アドレスに含まれる領域のサイズ変更

ロードモジュール５０の実行時仮想アドレスに含まれる領域の一部のサイズを変更する方法を取ることも可能である。例えば、heap領域やmmap領域などの作業用メモリ領域の仮想アドレスを制限する方法である。作業用メモリ領域と依存アドレス値の範囲とで、重複する部分がある場合には、heap領域又はmmap領域の仮想アドレス空間上の開始アドレス及び終了アドレスの一方又は両方を変更することによって、依存アドレス値の範囲と重畳しないように制御することが可能である。

また、依存アドレス値の範囲が、user stack領域の仮想アドレスと重複した場合も同様に、user stack領域の開始アドレス、又は使用サイズの上限を変更するように制御しても良い。

（４）他の重複回避方法

ロードモジュールの実行時仮想アドレスの領域の一部を分割するようにしても良い。例えば、依存アドレス値の範囲が、text領域及びdata領域と重畳する場合、依存アドレス値の範囲を避けるように、text/data領域を依存アドレス値の範囲の前後に分割して配置するようにしても良い。例えば、text領域を依存アドレス値の範囲の先頭アドレスより手前に配置し、data領域を依存アドレス値の範囲の最終アドレスより後ろに配置する。その際、text領域及びdataの領域を、依存アドレス値の範囲に隣接するように配置しても良い。

また、依存アドレス値の範囲がmmap領域と重複する場合、依存アドレス値の範囲がマップ済み、即ち使用済の仮想アドレスとして割り当てるようしても良い。mmap領域は、mmap()システムコールを使用して確保される領域であるので、リソースのマップも、mmap領域の一部として扱われるようにすることができる。すなわち、本来のmmap領域として使用される領域を小さくする。

同様に、依存アドレス値の範囲が、heap領域、或いはuser stack領域と重複する場合についても、同様に、依存アドレス値の範囲が、割当済のheap領域、user stack領域として扱われるようにしても良い。すなわち、本来のheap領域或いはuser stack領域として使用される領域を小さくする。

この場合、これらの領域は、スワップの対象外の領域となるので、そのようにメモリ管理上の制御を施すように設定する。ＯＳ３２がUnix（登録商標）系のＯＳの場合には、予め定められた拡張モジュールでLockシステムコールを用いるか、デバイスドライバ３６で同様の処理を実行すれば良い。また、例えば、ＯＳ３２がLinux（登録商標）の場合には、デバイスドライバ３６でこれらの領域のページメモリ用管理フラグを予約済み(RESERVED)にセットすることにより、カーネル３４のコード領域と同様にスワップの対象外とすることが可能である。

また、依存アドレス値の範囲がtext/data領域と重畳する場合、拡張モジュール中に、依存アドレスの範囲を含む埋草(パディング)のセクション、即ち機能上は使用しないダミーの領域を当該重複する部分に対応する位置に確保しておくこともできる。このダミー領域の仮想アドレスは、ステップＳ１０のマップの際に、依存アドレス値として扱われるように上書きするようにしても良い。これにより、ロードモジュール５０の実行時仮想アドレスを変更する手順が省略される。

（５）リンカによる実現

上記例では、ローダ３８によって実行時仮想アドレスの配置の変更を実現する方法を示したが、図５に示すように、移植対象プログラム５２及び拡張モジュール５４のリンクを実行するリンカ６０を用いて実現しても良い。具体的には、上記ステップＳ０２〜Ｓ０６の処理を実行するツール（アドレス管理ツール６２）を用意し、そのアドレス管理ツール６２から、ステップＳ０６で決定した変更後の実行時仮想アドレスの配置情報をリンクパラメータとして出力する。ステップＳ０７において、リンカ６０が、上記リンクパラメータを用いて、移植対象プログラム５２及び拡張モジュール５４をリンクしたロードモジュール５０を生成するようにしても良い。これにより、リンクパラメータにより実行時仮想アドレスが埋め込まれたロードモジュール５０が生成される。

（６）拡張モジュールの実装方法

上記では、拡張モジュール５４を、移植対象プログラム５２とリンクされるコンパイルユニットとして実現する方法を説明したが、これに限定されず、例えば、前述したように、拡張モジュール５４の機能を移植対象プログラムに組み込んでも良い。この場合、移植対象プログラム５２のプログラムコードにおいて、移植対象プログラム５２の初期化処理を実行する部分に、拡張モジュール５４が行う処理の記述を追加すれば良い。また、拡張モジュール５４を移植対象プログラム５２とリンクせず、独立したモジュールとして実現しても良い。例えば、共有ライブラリとして実現し、移植対象プログラム５２の初期化処理で拡張モジュール５４が提供する機能を呼び出すようにしても良い。

以上の例では、仮想アドレスを使用しないＯＳから仮想アドレスを使用するＯＳへの移植を例に説明したが、移植元のＯＳが仮想アドレスを使用するＯＳであって、移植対象のプログラムが、移植元のＯＳの仮想アドレス値に依存して実装されている場合であっても、上記と同様に処理することで移植時の問題を解決可能である。即ち、依存アドレスを移植先のリソースにマップし、依存アドレスが実行時仮想アドレス空間と重複する場合は実行時仮想アドレスが依存アドレスと重複しないように配置を変更すれば良い。

１０ 画像形成装置
１２ ＣＰＵ
１４ ＲＡＭ
１６ 記憶部
１８ ＩＯポート
２０ 通信インタフェース
３４ カーネル
３６ デバイスドライバ
３８ ローダ
４０ ハードウェア
５０ ロードモジュール
５２ 移植対象プログラム
５４ 拡張モジュール
６０ リンカ
６２ アドレス管理ツール

Claims (6)

1. 第１オペレーティングシステム上で動作させるために作成されたプログラムに固定値で指定されたアドレス値の範囲を取得する取得手段と、
   前記取得したアドレス値の範囲と、第２オペレーティングシステムの仮想アドレス空間上で前記プログラムを実行させるときに使用される実行時仮想アドレスの範囲と、が重複しないように、前記実行時仮想アドレスの前記仮想アドレス空間上における配置を変更する変更手段と、
   前記取得した範囲のアドレス値が前記第２オペレーティングシステムの仮想アドレス空間上の仮想アドレスとして用いられるように、前記仮想アドレス空間上の仮想アドレスと、前記第２オペレーティングシステムが管理する物理アドレス空間の物理アドレスと、を対応付けるテーブルを設定する設定手段と、
   を備えたアドレス管理装置。
2. 前記変更手段は、予め定められた配置単位毎に、前記実行時仮想アドレスの配置を変更する
   請求項１に記載のアドレス管理装置。
3. 前記変更手段は、前記配置単位を、前記取得したアドレス値の範囲のサイズに応じて決定する
   請求項２に記載のアドレス管理装置。
4. 前記変更手段は、前記実行時仮想アドレスの配置の変更が失敗した場合には、該配置の変更が失敗したときに用いた配置単位よりも小さな配置単位で、前記実行時仮想アドレスの配置を変更する
   請求項２又は請求項３に記載のアドレス管理装置。
5. 前記変更手段は、前記取得した範囲が、前記実行時仮想アドレスの作業用領域又はスタック領域に重畳する場合には、前記実行時仮想アドレスの前記重畳する範囲を減少させて、前記実行時仮想アドレスの配置を変更する
   請求項１〜請求項４の何れか１項記載のアドレス管理装置。
6. コンピュータを、
   第１オペレーティングシステム上で動作させるために作成されたプログラムに固定値で指定されたアドレス値の範囲を取得する取得手段、
   前記取得したアドレス値の範囲と、第２オペレーティングシステムの仮想アドレス空間上で前記プログラムを実行させるときに使用される実行時仮想アドレスの範囲と、が重複しないように、前記実行時仮想アドレスの前記仮想アドレス空間上における配置を変更する変更手段、及び
   前記取得した範囲のアドレス値が前記第２オペレーティングシステムの仮想アドレス空間上の仮想アドレスとして用いられるように、前記仮想アドレス空間上の仮想アドレスと、前記第２オペレーティングシステムが管理する物理アドレス空間の物理アドレスと、を対応付けるテーブルを設定する設定手段、
   として機能させるためのプログラム。

Images