JP6143038B1 - アプリケーションに依存することなくファイルにアクセスするｏｓプログラム及び方法 - Google Patents

Abstract

【課題】アプリケーションのファイル形式に依存することなく、そのデータファイルにアクセスすることができるＯＳプログラム及び方法を提供する。【解決手段】アプリケーションプログラムによって入出力されるデータファイルには、当該アプリケーションプログラム専用のファイル操作モジュールが含まれている。最初に、アプリケーションプログラム毎に、ファイル操作開始時に、対象となるデータファイルのファイル形式専用のファイル操作モジュールを、メモリ上にロードする。次に、アプリケーションプログラムから、ファイル操作共通インタフェースにアクセスされた際に、当該ファイル操作共通インタフェースから、当該アプリケーションプログラム専用のメモリ上のファイル操作モジュールへアクセスする。そして、メモリ上の当該ファイル操作モジュールからファイルシステムへアクセスする。【選択図】図３

Description

本発明は、ファイルにアクセスするＯＳ(Operating System)プログラムの技術に関する。

Unix（登録商標）やWindows（登録商標）に代表されるＯＳプログラムは、当然にファイルシステムを内在している。「ファイルシステム」とは、ストレージデバイス（補助記憶装置、例えばＨＤＤ(Hard Disk Drive)やＳＳＤ(Solid State Drive)）との間でファイル（データ）を操作するためのファイル管理機能である。ファイルシステムは、アプリケーションプログラムから見てストレージデバイスに対するデータの格納状態を隠蔽する。

図１は、従来技術におけるファイルアクセスの構成図である。

ＯＳプログラムは、装置に搭載されたハードウェアとしてのプロセッサ（コンピュータ）の実行によって機能する。プロセッサは、ＯＳプログラムと共に、アプリケーションプログラムと、デバイスドライバとを実行し、ＨＤＤやＳＳＤのようなストレージデバイスにアクセスする。ストレージデバイスには、ＯＳプログラムによってアクセスされるデータファイルの実体が蓄積されている。

図１によれば、各アプリケーションプログラムは、ファイルシステムへアクセスするファイル操作モジュールを個別に内部に保有する。ファイル操作モジュールは、ＯＳプログラムによって提供される標準のシステムコールインタフェースを用いてシステムプログラミングとして記述されたものである。ファイル操作モジュールは、アプリケーションプログラム毎に異なり、データファイルの構造（ファイル形式）も固有となる（別個に異なる）。各アプリケーションプログラムからアクセスされるＯＳのファイルシステムは、ファイル操作共通インタフェース（open, close, read, write等）を有する。アプリケーションプログラム毎に、そのデータファイルに対するアクセスは、その固有の構造を知っているファイル操作モジュールによってのみ実行される。

前述した従来技術によれば、一方のアプリケーションプログラムＡは、他方のアプリケーションプログラムＢのデータファイル構造（ファイル形式）を知らない。そのために、アプリケーションプログラムＢがインストールされていない限り、アプリケーションプログラムＢのデータファイルにアクセスすることは当然にできない。

また、将来的に当該アプリケーションプログラム自体の配布が停止した場合、過去の遺産としてのデータファイルにアクセスすることができなくなる。

更に、ドライブレコーダに記録されたデータファイルの場合、特に問題が生じる。このようなデータファイルは、映像・音声のみならず、運行データも含まれるために、そのアプリケーションプログラム専用のファイル形式で記録される場合が多い。このようなデータファイルに、特定のアプリケーションからしかアクセスできない場合、事故処理作業（例えば警察による事故原因の検証）にも支障をきたすこともある。

そこで、本発明は、アプリケーションのファイル形式に依存することなく、そのデータファイルにアクセスすることができるＯＳプログラム及び方法を提供することを目的とする。

本発明によれば、アプリケーションプログラム毎に、ファイルシステムへアクセスするファイル操作モジュール（手続プログラム）が異なっており、各アプリケーションプログラムからファイルシステムへアクセスするようにコンピュータを実行するＯＳ(Operating System)プログラムにおいて、
アプリケーションプログラムによって入出力されるデータファイルには、当該アプリケーションプログラム専用であってファイルシステムのシステムコールを実行するファイル操作モジュールが含まれており、
アプリケーションプログラム毎に、ファイル操作開始時に、対象となるデータファイルからファイル操作モジュールを、メモリ上にロードする第１のステップと、
アプリケーションプログラムから、ファイル操作共通インタフェースとしてのファイル操作のシステムコールが呼び出された際に、当該ファイル操作共通インタフェースから、当該アプリケーションプログラム専用のメモリ上のファイル操作モジュールへアクセスする第２のステップと、
メモリ上の当該ファイル操作モジュールからファイルシステムのシステムコールを実行する第３のステップと
をコンピュータが実行することを特徴とする。

本発明のＯＳプログラムにおける他の実施形態によれば、
データファイルは、当該データファイルに基づくファイル形式に依存しないアクセスを可能とする
ようにコンピュータを実行することも好ましい。

本発明のＯＳプログラムにおける他の実施形態によれば、
データファイルは、運行時に逐次に記録される運行データを記録したものであり、当該データファイルに基づくファイル形式に依存することなく、運行データを読み取ることができる
ようにコンピュータを実行することも好ましい。

本発明のＯＳプログラムにおける他の実施形態によれば、
第１のステップの前段階で、アプリケーションプログラム毎に、ファイル操作モジュールの宣言を記述したアクセス管理構造体を作成する初期化ステップを更に有し、
第１のステップについて、当該アプリケーションプログラム専用のファイル操作モジュールをメモリ上にロードして定義し、当該定義とアクセス管理構造体の宣言とを対応付け、
第２のステップについて、当該ファイル操作共通インタフェースから、当該アプリケーションプログラム専用のアクセス管理構造体の宣言を介して、メモリ上に定義されたファイル操作モジュールへアクセスする
ようにコンピュータを実行することも好ましい。

本発明のＯＳプログラムにおける他の実施形態によれば、
第１のステップについて、ファイル操作開始時とは、当該データファイルに対するopen操作時である
ようにコンピュータを実行することも好ましい。

本発明によれば、アプリケーションプログラム毎に、ファイルシステムへアクセスするファイル操作モジュール（手続プログラム）が異なっており、各アプリケーションプログラムからファイルシステムへアクセスする、ＯＳのファイルアクセス方法において、
アプリケーションプログラムによって入出力されるデータファイルには、当該アプリケーションプログラム専用であってファイルシステムのシステムコールを実行するファイル操作モジュールが含まれており、
アプリケーションプログラム毎に、ファイル操作開始時に、対象となるデータファイルからファイル操作モジュールを、メモリ上にロードする第１のステップと、
アプリケーションプログラムから、ファイル操作共通インタフェースとしてのファイル操作のシステムコールが呼び出された際に、当該ファイル操作共通インタフェースから、当該アプリケーションプログラム専用のメモリ上のファイル操作モジュールへアクセスする第２のステップと、
メモリ上の当該ファイル操作モジュールからファイルシステムのシステムコールを実行する第３のステップと
を有することを特徴とする。

本発明のＯＳプログラム及び方法によれば、アプリケーションのファイル形式に依存することなく、そのデータファイルにアクセスすることができる。即ち、データファイルは、当該データファイルに基づくファイル形式に依存しないアクセスを可能とする。

従来技術におけるファイルアクセスの構成図である。 本発明におけるデータファイル構造を表す説明図である。 本発明における処理ステップを表す説明図である。 本発明における処理コードの例である。 本発明におけるファイルアクセスの構成図である。 本発明におけるファイル操作共通インタフェースの例である。 本発明のＯＳプログラムを搭載したドライブレコーダの外観図である。

以下、本発明の実施の形態について、図面を用いて詳細に説明する。

図２は、本発明におけるデータファイル構造を表す説明図である。

アプリケーションプログラムによって入出力されるデータファイルには、当該アプリケーションプログラム専用の「ファイル操作モジュール」が含まれている。図２によれば、データファイルは、「ヘッダ」「モジュール格納領域」「データ本体」から構成される。
ヘッダ ：モジュール及びデータ本体に対する「宣言」が記述される
モジュール格納領域：各ファイル操作モジュールの「定義」（本体）が格納される
データ本体 ：データファイルのデータ
ファイル操作モジュールとは、例えばopen、close、read、writeのようなファイル操作に基づく手続プログラムであって、そのファイル形式専用のものである。

図３は、本発明における処理ステップを表す説明図である。
図４は、本発明における処理コードの例である。

アプリケーションプログラムは、ファイル操作開始時に、例えば以下のファイル操作共通インタフェースを呼び出す。
obj_file_open(char *ファイル名) ;

（Ｓ０：初期化ステップ）
最初に、アプリケーションプログラム毎に、ファイル操作モジュールの宣言を記述したアクセス管理構造体を作成する。「宣言」とは、メモリ上のソースファイルに存在する関数を知らせるためのものであって、ヘッダとして記述される。
図４のＳ０によれば、method_areaによって領域が確保されている。
尚、アクセス管理構造体は、openしたデータファイルごとに用意される。

（Ｓ１：第１のステップ）
アプリケーションプログラム毎に、ファイル操作開始時に、対象となるデータファイルのファイル形式専用のファイル操作モジュールを、メモリ上にロードする。ここで、ファイル操作開始時とは、当該データファイルに対するopen操作時である。
図４のＳ１によれば、load_methodsによって、ファイル操作モジュールがメモリ上にロードされる。

次に、当該アプリケーションプログラム専用のファイル操作モジュールをメモリ上にロードして定義し、当該「定義」とアクセス管理構造体の「宣言」とを対応付ける。宣言と定義とを結び付けることによって、外部シンボルを解決する。「定義」とは、実際に関数の作成を依頼するためのものであって、ソースファイルとして記述される。定義は全ソースファイルで唯一に存在する。

本発明によれば、アプリケーション作成事業者は、自ら作成するアプリケーションプログラムにファイル操作モジュールを含めることなく、その「雛形ファイル」を用意する。「雛形ファイル」は、データ内容が初期値によって空となっているが、ファイル操作モジュールの手続プログラム一式が含まれたものである。アプリケーション作成事業者は、新しい種類のデータ型を定義した場合、その「雛形ファイル」を提供しなければならない。

（Ｓ２：第２のステップ）
アプリケーションプログラムから、ファイル操作共通インタフェースにアクセスされた際に、当該ファイル操作共通インタフェースから、当該アプリケーションプログラム専用のメモリ上のファイル操作モジュールへアクセスする。即ち、当該ファイル操作共通インタフェースから、当該アプリケーションプログラム専用のアクセス管理構造体の「宣言」を介して、メモリ上に「定義」されたファイル操作モジュールへアクセスする（動的リンクの拡張方法）。具体的には、アクセス管理構造体における未解決の関数アドレスを、メモリ上に読み込んだ関数実体を指すポインタによって解決する。

（Ｓ３：第３のステップ）
メモリ上の当該ファイル操作モジュールからファイルシステムへアクセスする。ファイルシステムへのアクセスは、標準ＯＳのファイルシステムに関する低水準システムコールである。

図５は、本発明におけるファイルアクセスの構成図である。

図５によれば、アプリケーションＡプログラムとアプリケーションＢプログラムとがopenされている場合、各アプリケーションプログラムから、ファイル操作共通インタフェースを介して、当該アプリケーションプログラム専用のメモリ上のファイル操作モジュールへアクセスすることができる。

ファイル操作共通インタフェースからは、１回の間接のアドレス参照によってファイル操作モジュールへアクセスできるために、呼び出し（jump(call)）のオーバヘッドは極めて小さい。これは、ＯＳのカーネルに置かれる通常のシステムコールのオーバヘッドと比較すると、無視できるほどに小さい。

最後に、当該データファイルに対するファイル操作終了時に、例えば以下のファイル操作共通インタフェースを呼び出す。
obj_file_close();
当該データファイルをcloseした場合、当該アクセス管理構造体もメモリ上から削除される。

図６は、本発明におけるファイル操作共通インタフェースの例である。

図６によれば、オープン、クローズ、バイト列読み出し、レコード読み出し、パラグラフ読み出し、読み出しポイントの進行／後退、及び、レンダリングについて、アプリケーションから呼び出される標準のファイル操作共通インタフェースが表されている。図２のモジュール定義や、図３の手続宣言アドレス及び手続定義モジュールは、ファイル操作共通インタフェース毎にそれぞれ用意される。ファイル操作共通インタフェースは、ＯＳインタフェースであってもよいし、ＯＳに対するユーザ空間のライブラリであってもよい。

勿論、ファイル操作共通インタフェースは、言語体系を問わない。ＣＰＵアーキテクチャや実行プラットフォームが限定されるもののＣ言語（コンパイル後は機械語）であってもよいし、Lisp等のインタープリタ言語、Java（登録商標）やruby（コンパイル後の仮想機械(JavaVM, ruby VMの機械語）であってもよい。

以上、詳細に説明したように、本発明のＯＳプログラム及び方法によれば、アプリケーションのファイル形式に依存することなく、そのデータファイルにアクセスすることができる。即ち、データファイルは、当該データファイルに基づくアプリケーションプログラム以外のアプリケーションプログラムからのアクセスを可能とする。

具体的には、本発明によれば、データファイルが、ファイル操作モジュール（手続プログラム）を含むために、アプリケーションは、データファイルの種類毎に個別に、手続プログラムを用意する必要がない。また、１つのアプリケーションプログラムから、他の複数のアプリケーションプログラム専用のデータファイルにアクセスすることができ（データファイルのポータビリティの向上）、様々なサービスを想定することができる。

本発明のＯＳプログラムを実装する装置としては、例えば個人管理データベースに適用できる。近年、個人情報を蓄積した端末は、悪意の第三者によってネットワークを介して読み取られないようにセキュリティ機能を高めると共に、過去の遺産情報を大量に保持する。これに対し、本発明のＯＳプログラムを適用した場合、異なる種類の多数のデータファイルに対して、１つのアプリケーションプログラムからアクセスすることができる。特に、自動車に搭載するコンピュータシステムにおける記憶装置の場合、個人情報や自動車制御情報等の様々なデータファイルが蓄積される。データファイルの秘匿性や耐改ざん性を高めることとは別に、様々なデータファイルに対してアクセス可能とすることは、個人情報のビッグデータ化時代には必須の要素技術と成り得る。

図７は、本発明のＯＳプログラムを搭載したドライブレコーダの外観図である。

本発明のＯＳプログラムは、当該データファイルのファイル形式に依存しないアクセスを可能とする。これは、例えばドライブレコーダに搭載するＯＳプログラムとして有効である。「ドライブレコーダ」とは、車両の運行データを記録する装置をいう。運行データとは、例えば、走行中の車内外を撮影した映像及び音声のみならず、時間経過に基づく走行速度及び加速度も含まれる。記録された運行データは、一般に、交通事故の検証のために用いられる場合が多い。事故の状況は、当事者の主観的な記憶ではなく、ドライブレコーダによる客観的な記録によって判断することができる。ドライブレコーダは、例えば、数分間の運行データを上書きしながら記録し続ける。そして、速度又は加速度における急変といった衝撃を検知した際に、その前後の一定時間の運行データが保存される。

ここで、ドライブレコーダに記録されたデータファイルは、映像・音声のみならず、運行データも含まれるために、そのアプリケーションプログラムのファイル形式専用のデータ構造で記録される場合が多い。このようなデータファイルに、そのファイル形式に対応したアプリケーションからしかアクセスできない場合、事故処理作業（例えば警察による事故の検証）にも支障をきたす場合がある。本発明のＯＳプログラムをドライブレコーダに搭載することによって、データファイルに基づくファイル形式に依存しないアクセスを可能とする。

前述した本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。

Ｓ０ 初期化ステップ
Ｓ１ 第１のステップ
Ｓ２ 第２のステップ
Ｓ３ 第３のステップ

Claims (6)

1. アプリケーションプログラム毎に、ファイルシステムへアクセスするファイル操作モジュール（手続プログラム）が異なっており、各アプリケーションプログラムからファイルシステムへアクセスするようにコンピュータを実行するＯＳ(Operating System)プログラムにおいて、
   アプリケーションプログラムによって入出力されるデータファイルには、当該アプリケーションプログラム専用であってファイルシステムのシステムコールを実行するファイル操作モジュールが含まれており、
   アプリケーションプログラム毎に、ファイル操作開始時に、対象となるデータファイルからファイル操作モジュールを、メモリ上にロードする第１のステップと、
   前記アプリケーションプログラムから、ファイル操作共通インタフェースとしてのファイル操作のシステムコールが呼び出された際に、当該ファイル操作共通インタフェースから、当該アプリケーションプログラム専用のメモリ上のファイル操作モジュールへアクセスする第２のステップと、
   メモリ上の当該ファイル操作モジュールからファイルシステムのシステムコールを実行する第３のステップと
   をコンピュータが実行することを特徴とするＯＳプログラム。
2. 前記データファイルは、当該データファイルに基づくファイル形式に依存しないアクセスを可能とする
   ようにコンピュータを実行することを特徴とする請求項１に記載のＯＳプログラム。
3. 前記データファイルは、運行時に逐次に記録される運行データを記録したものであり、当該データファイルに基づくファイル形式に依存することなく、前記運行データを読み取ることができる
   ようにコンピュータを実行することを特徴とする請求項１又は２に記載のＯＳプログラム。
4. 第１のステップの前段階で、アプリケーションプログラム毎に、ファイル操作モジュールの宣言を記述したアクセス管理構造体を作成する初期化ステップを更に有し、
   第１のステップについて、当該アプリケーションプログラム専用のファイル操作モジュールをメモリ上にロードして定義し、当該定義とアクセス管理構造体の前記宣言とを対応付け、
   第２のステップについて、当該ファイル操作共通インタフェースから、当該アプリケーションプログラム専用の前記アクセス管理構造体の宣言を介して、メモリ上に定義されたファイル操作モジュールへアクセスする
   ようにコンピュータを実行することを特徴とする請求項１から３のいずれか１項に記載のＯＳプログラム。
5. 第１のステップについて、ファイル操作開始時とは、当該データファイルに対するopen操作時である
   ようにコンピュータを実行することを特徴とする請求項１から４のいずれか１項に記載のＯＳプログラム。
6. アプリケーションプログラム毎に、ファイルシステムへアクセスするファイル操作モジュール（手続プログラム）が異なっており、各アプリケーションプログラムからファイルシステムへアクセスする、ＯＳのファイルアクセス方法において、
   アプリケーションプログラムによって入出力されるデータファイルには、当該アプリケーションプログラム専用であってファイルシステムのシステムコールを実行するファイル操作モジュールが含まれており、
   アプリケーションプログラム毎に、ファイル操作開始時に、対象となるデータファイルからファイル操作モジュールを、メモリ上にロードする第１のステップと、
   前記アプリケーションプログラムから、ファイル操作共通インタフェースとしてのファイル操作のシステムコールが呼び出された際に、当該ファイル操作共通インタフェースから、当該アプリケーションプログラム専用のメモリ上のファイル操作モジュールへアクセスする第２のステップと、
   メモリ上の当該ファイル操作モジュールからファイルシステムのシステムコールを実行する第３のステップと
   を有することを特徴とするＯＳのファイルアクセス方法。

Images