JP2008217611A - 情報処理装置、その起動方法及び起動プログラム - Google Patents

Abstract

【課題】情報処理装置の起動処理において、装置のユーザがユーザレベル機能を使用可能となるタイミングについて、早期化を実現する。
【解決手段】情報処理装置のオペレーティングシステムのカーネル１００に、ブロックモジュール３００を組み込む。ブロックモジュール３００は、情報処理装置のカーネルによる起動処理において実行される、デバイス１０１に対しての初期化処理に対して、あらかじめ作成した条件（ブロック条件３０１−１）に従い、処理要求ブロックを実行し、オペレーティングシステム起動処理全体の初期化処理順序を再配置し、制御する。
【選択図】図１

Description

本発明は、情報処理装置、情報処理装置の起動方法及び起動プログラムに関し、特に、オペレーティングシステムのユーザレベル機能を起動処理の早期にユーザに提供する技術に関する。

従来「オペレーティングシステム（以下、ＯＳ）起動処理」では、「カーネル起動処理」が完了した後に、「ユーザレベル機能」の起動処理を実施していた。

これは「カーネル起動処理」内で、「ユーザレベル機能」の起動開始が行える環境（メモリ空間など）を構築するために、このような順序になっている。

しかし「カーネル起動処理」内で最も処理時間が掛かっているのは「デバイス」の初期化処理であった。

つまり「ユーザレベル機能」の起動開始が行える環境の構築処理が完了しても、「デバイス」の初期化処理が終わらなければ、実際には「ユーザレベル機能」の起動開始が実施されないのである。

確かに「ユーザレベル機能」の起動処理において「デバイス」に対して処理の要求を行う場合もあり、「デバイス」の初期化処理が先に完了していることが必要ではあるが、あくまでここでの「デバイス」とは、「ユーザレベル機能」の起動処理において必要とするデバイスであり、システムとして搭載されているすべての「デバイス」を指すのでは無い。言うなれば「ユーザレベル機能」の起動処理において必要な「デバイス」のみ、初期化処理が完了してさえいれば良く、すべての「デバイス」の初期化が完了するのを、「ユーザレベル機能」の起動処理が待つ必要は無いのである。

近年、システムに対する高機能化の要求が高まってきており、システムに搭載される「デバイス」や「ユーザレベル機能」は増加している。

「デバイス」の増加に伴い、すべての「デバイス」の初期化が完了するまでの時間も増加し、システムの「ユーザレベル機能」を使用するユーザは、「ユーザレベル機能」の起動処理が完了するまで「ＯＳ起動処理」の開始時点から長く待たされることとなり、問題となっていた。

つまり、高機能化というユーザに対しての利益をシステムは提供しながら、ユーザは「ユーザレベル機能」の使用開始が可能な時点まで長く待たされるという不利益もシステムは提供してしまっていたことになる。

こうした問題の解決を図った従来技術としては、特許文献１ないし３に開示されたものがある。特許文献１には、例えば段落００１６−００１８に、デバイス処理要求を保留及び保留解除にする技術が記載されている。また、特許文献２には、例えば段落００１５−００１６に、通常起動処理及び高速起動処理の２種を提供する情報処理装置であって、各種デバイスを初期化する処理のうち一部を省略する技術が記載されている。また、特許文献３には、例えば段落００３８−００４６に、カーネルとは独立してデバイスドライバの読み込みを行う機能を有するダイナミックドライバローダを備えてＯＳの起動処理を行う技術が記載されている。
特開２００６−１２７１７９号公報 特開２００６−２５２３２９号公報 特開平０９−０４４４３７号公報

下記の説明により、より詳細に、上記のような従来技術の問題点を明らかにする。

図２２を参照すると、ＯＳのコアである「カーネル」１００を有し、任意の数の「デバイス」１０１と、ＯＳとして提供する「ユーザレベル機能（デーモン、アプリケーションなど）」１０２を任意の数搭載する従来システムの構成が示されている。

また、図２３を参照すると、図２２に示したシステムに電源が投入された後に実施される「ＯＳ起動処理」２００の流れが示されている。

図２３に示すとおり「ＯＳ起動処理」２００は、任意の数の「デバイス」１０１を初期化する処理を含んだ「カーネル起動処理」２０１部分と、任意の数の「ユーザレベル機能」１０２の起動処理を実施する「ユーザレベル機能起動処理群」２０２に分別することが出来る。

システムを利用するユーザにとって、「ユーザレベル機能」１０２が使用可能となるのは、この図２に示すとおり「カーネル起動処理」２０１の完了後であり、「ＯＳ起動処理」２００の後半部分となっている。

つまり、「ユーザレベル機能」１０２が使用可能となるまでに「カーネル起動処理」２０１の完了を待ち合わせている形となる。

この「カーネル起動処理」２０１では、「デバイス」１０１を初期化する処理を含んでおり、システムに搭載される「デバイス」１０１数の増加に伴い「カーネル起動処理」２０１時間も増加する。

つまりシステムに搭載される「デバイス」１０１数が増加すると、「ユーザレベル機能」１０２が使用可能となるまでの時間が長くなる。

従来では、搭載される「デバイス」１０１の数は限られており、搭載「デバイス」１０１の数の増加に伴い増加する「カーネル起動処理」２０１という時間は実質的に少なく、特に問題とされていなかった。

しかし技術的な発展により、カーネル１００を有し、任意の数の「デバイス」１０１と、ＯＳとして提供する「ユーザレベル機能」１０２を任意の数搭載するシステムにおいて、より多くの種類のデバイスをシステムとして搭載することが可能となった。

こうした、デバイスの数に応じて増加する「カーネル起動処理」２０１という時間は、ユーザにとって電源が投入されてから「ユーザレベル機能」１０２が使用可能となるまでの時間が長くなる、という課題生み出し、この課題は近年問題となっていた。

なお、上記特許文献１ないし３に記載の従来技術は、いずれも本発明とは目的に共通点があるものの、その解決手段において全く異なる従来技術である。

そこで本発明は、従来技術の問題点に鑑み、情報処理装置の起動処理において、装置のユーザがユーザレベル機能を使用可能となるタイミングについて、早期化を実現することを目的とする。

上記目的を達成するための請求項１記載の発明は、オペレーティングシステムを格納する記憶手段を有する情報処理装置の起動方法であって、前記オペレーティングシステムのカーネルに組み込まれたブロックモジュールが、前記カーネルの行う前記情報処理装置の各デバイスの初期化処理を、前記ブロックモジュールの記憶するブロック条件に基づいて、実行させないブロック処理と、該ブロック処理の後、前記ブロックモジュールが、前記オペレーティングシステムの提供するユーザレベル機能を、前記カーネルに起動させるユーザレベル機能起動処理と、該ユーザレベル起動処理の後、前記カーネルが、前記各デバイスの初期化を行うデバイス初期化処理と、を有することを特徴とする情報処理装置の起動方法である。

請求項２記載の発明は、請求項１記載の情報処理装置の起動方法において、前記ブロック処理により、デバイスの初期化処理が実行されなかったデバイスにつき、該デバイスから状態変化通知を受けたこと、及び、前記ブロックモジュールが定期的にデバイスの状態を参照したことのいずれか１つ以上のトリガによって、前記カーネルが、前記デバイスのブロックを解除するブロック解除処理を有することを特徴とする。

請求項３記載の発明は、請求項１又は２記載の情報処理装置の起動方法において、前記ユーザレベル機能と前記各デバイスとの処理のやり取りを、情報として採取する情報採取処理を有し、前記ブロック条件は、前記情報採取処理に基づいて作成することを特徴とする。

請求項４記載の発明は、請求項１から３のいずれか１項記載の情報処理装置の起動方法において、前記ブロック条件は、情報処理装置の各デバイスの構成に変更があった際に、条件の入れ替えが実行されることを特徴とする。

請求項５記載の発明は、オペレーティングシステムを格納する記憶手段を有する情報処理装置であって、前記オペレーティングシステムのカーネルに組み込まれたブロックモジュールと、該ブロックモジュールが記憶するブロック条件と、を有し、前記カーネルは、前記情報処理装置の起動処理の際、前記ブロック条件に基づいて、前記情報処理装置の各デバイスの初期化処理を、前記ブロック条件がブロックするデバイスについては実行させず、前記ブロックモジュールは、前記オペレーティングシステムの提供するユーザレベル機能を、前記各デバイスの初期化処理に先立ってユーザに提供するよう、前記オペレーティングシステムの起動処理の再配置を実行することを特徴とする情報処理装置である。

請求項６記載の発明は、オペレーティングシステムを格納する記憶手段を有する情報処理装置に前記オペレーティングシステムの起動処理を実行させる起動プログラムであって、前記情報処理装置に、前記オペレーティングシステムのカーネルに組み込まれたブロックモジュールが、前記カーネルの行う前記情報処理装置の各デバイスの初期化処理を、前記ブロックモジュールの記憶するブロック条件に基づいて、実行させないブロック処理と、該ブロック処理の後、前記ブロックモジュールが、前記オペレーティングシステムの提供するユーザレベル機能を、前記カーネルに起動させるユーザレベル機能起動処理と、該ユーザレベル起動処理の後、前記カーネルが、前記各デバイスの初期化を行うデバイス初期化処理と、を実行させることを特徴とする起動プログラムである。

本発明によれば、情報処理装置の起動処理において、装置のユーザがユーザレベル機能を使用可能となるタイミングについて、早期化を実現することができる。

以下に、本発明の好適な実施形態について図面を参照して説明する。

本実施形態のハードウェア構成は、好適には記憶装置にＯＳが格納されている情報処理装置である。情報処理装置の例としては、本発明を特に限定するものではないが、パーソナルコンピュータやワークステーションなどの電子計算機や、エンベデッドＯＳによるマイコン応用システム等がある。次に、本実施形態の機能構成について説明する。

図１を参照すると、本実施形態の機能構成が示されている。本実施形態は、「ブロックモジュール」３００を「カーネル」１００に組み込み、「ブロック条件」３０１−１に従い「ＯＳ起動処理」２００内の処理順序を制御することで、「ユーザレベル機能」１０２の起動処理の完了を前倒しすることが可能となり、ユーザへの「ユーザレベル機能」１０２の提供を早期化することを、要旨とする。

以下に挙げる第１から３の３つの構成要素の少なくとも第１を含む要素にて、ユーザへの「ユーザレベル機能」１０２の提供の早期化を実現する。第１の構成要素は、「ユーザレベル機能」１０２の起動処理開始の再配置である。次に、第２の構成要素は、ブロック手段である。次に、第３の構成要素は、ブロック解除手段である。詳細は後述する。

まず、第１の構成要素、「ユーザレベル機能」１０２の起動処理開始の再配置について説明する。これはすなわち、「ユーザレベル機能」１０２の起動開始を早めるために起動開始処理を前倒しするものである。

詳細には、「ユーザレベル機能」１０２の起動処理開始を早めるために、「ユーザレベル機能」１０２の起動処理を、「ＯＳ起動処理」２００の初期段階、つまり「カーネル起動処理」２０１内での該当「デバイス」１０１を初期化する時点より先に開始するよう、処理順序の再配置を実施する。

再配置を実施することで、「ユーザレベル機能」１０２の起動処理開始タイミングが早まる。また、「ユーザレベル機能」１０２の起動処理に掛かる時間は、「ユーザレベル機能」１０２の起動処理開始が早まれば、「ユーザレベル機能」１０２の起動処理完了も早まり、結果としてユーザに対しての「ユーザレベル機能」１０２の提供タイミングも早まる。

図２は、本実施形態の階層構成を説明するための図である。図２に示すような、「ユーザレベル機能」１０２のα、β、γと「デバイス」１０１のＡ、Ｂ、Ｃ、Ｄが存在するシステム構成において、本実施形態の第１の構成要素である『「ユーザレベル機能」１０２の起動処理開始の再配置』を実施する前と実施した後での比較を示した図として図３に示す。図３を参照すると、ＯＳ起動処理２００において、ユーザレベル機能の起動処理の前倒しが実行されることが分かる。

次に、第２の構成要素、ブロック手段について説明する。これはすなわち、「ユーザレベル機能」１０２が使用する「デバイス」１０１への要求が継続出来ずブロックすべき条件（例：初期化が未完了の場合）に該当する場合に、このデバイス要求をブロックするものである。本要素を、図４を参照して説明する。

単純に第１要素を実施しても、「ユーザレベル機能」１０２の起動処理が正常に完了しない可能性が存在する。

これは、「ユーザレベル機能」１０２の起動処理において、「デバイス」１０１に対して、何らかの処理要求を実施する場合、第１要素で実施した「ユーザレベル機能」１０２の起動処理開始の再配置により、この要求が該当「デバイス」１０１の初期化を実施する前で行われてしまう、という処理順序の矛盾が生じる可能性があるからである。この矛盾は「ユーザレベル機能」１０２の起動の失敗や、「ユーザレベル機能」１０２を提供することが出来ないという問題を引き起こす。

こうした問題に対応するために、「ユーザレベル機能」１０２からの「デバイス」１０１に対しての要求処理を、該当「デバイス」１０１の初期化処理完了後までブロックする手段が必要となる。

このように、「デバイス」１０１への要求をブロックすべき状態の場合に、この「デバイス」１０１への要求処理をブロックするブロック手段を実現するモジュールとして、本実施形態は、「ブロックモジュール」３００を提供する。

また、「ブロックモジュール」３００が実施する「デバイス」１０１に対しての要求処理に関してブロックする／しないを判定する際に、ブロックする条件を「ブロック条件」３０１−１と定義する。「ブロック条件」３０１−１は、実際にシステム内に組み込まれた「ブロックモジュール」３００から参照出来るように、コード化を実施し「コード化されたブロック条件」３０１−２として作成する。

次に、第３の構成要素、ブロック解除手段について説明する。これはすなわち、「ブロックモジュール」３００にてブロックしている「ユーザレベル機能」１０２の起動処理からの「デバイス」１０１に対しての要求処理を、ブロック解除して処理の実行を継続する手段である。図５を参照して説明する。

ブロックの解除は、「ブロック条件」３０１−１を用いて判定し、「デバイス」１０１への要求が継続出来る状態になればブロックを解除する。

ブロックを解除するか否かの判断は、「デバイス」１０１の状態を基に判断するが、その判断のタイミングは、「デバイス」１０１自身の状態が変化する場合（例：初期化完了）に「ブロックモジュール」３００に通知させその通知をトリガとして判断しても良いし、「ブロックモジュール」３００が「デバイス」１０１の状態変化を監視することで実現しても良い。また、これらを組み合わせても良い。

上述した３つの構成要素を適用したシステムの構成図が、前掲の図１である。以下、さらに詳細に本実施形態の構成及び動作について説明する。

再度本実施形態の目的について確認すると、本実施形態の目的は、ＯＳのコアである「カーネル」１００を有し、任意の数の「デバイス」１０１と、ＯＳとして提供する「ユーザレベル機能」１０２を任意の数搭載するシステムに関して、システムを使用するユーザに対して「ユーザレベル機能」１０２の提供を早期化するものである。

そこで、本実施形態を処理の流れに着目して大きく分けると、「１．ブロック条件作成」と「２．処理の再配置」と「３．ブロック制御によるＯＳ起動処理」の、３つのセクションに分かれる。したがって、以下、それぞれについて概略を説明し、さらにその後、それぞれについて詳細に説明を加える。

「１．ブロック条件作成」
本実施形態では、最初に３つの処理を実施し「コード化されたブロック条件」３０１−２を作成する。この作成した「コード化されたブロック条件」３０１−２を解決手段に適用することで、ユーザに対して「ユーザレベル機能」１０２の提供を早期化することを実現する。当該３つの処理の流れを図６として示す。

次に、図６で示した順序で実施される、３つの処理の概要について説明する。

「情報採取」ステップＳ４００は、「ユーザレベル機能」１０２の起動処理の内容と、「ユーザレベル機能」１０２の起動処理と「デバイス」１０１との処理のやり取りを、情報として採取する処理である。ステップＳ４００の後、ステップＳ４０１に進む。

「『ブロック条件』作成」ステップＳ４０１は、「情報採取」４００で採取された「ユーザレベル機能」１０２の起動処理の情報を分析し「ブロック条件」３０１−１を作成する処理である。ステップＳ４０１の後、ステップＳ４０２に進む。

「『ブロック条件』のコード化」ステップＳ４０２は、「『ブロック条件』作成」４０１処理で作成された「ブロック条件」３０１−１を「ブロックモジュール」３００から参照可能な形にコード化する処理である。

図７、図８は、上述の３つの処理に必要となるモジュールを説明するための図である。

図７は、「カーネル」１００内に組み込まれた「情報採取モジュール」５００を表す。

図８は、「情報採取モジュール」５００と「解析モジュール」５０１、「ブロック条件コード化モジュール」５０２を表す。なお、図８中において、実線で示した矢印は、処理のインプット、破線で示した矢印は、処理のアウトプットを表す。

「情報採取モジュール」５００は、「ユーザレベル機能」１０２の起動処理の内容と、「ユーザレベル機能」１０２の起動処理と「デバイス」１０１との処理のやり取りを、情報として採取する「カーネル」１００に組み込むことが可能なモジュールである。

一方、「解析モジュール」５０１は、「ブロック条件」３０１−１を作成するモジュールであり、「ブロック条件コード化モジュール」５０２はその「ブロック条件」３０１−１のコード化を実施するモジュールである。

「ブロック条件」３０１−１は、「情報採取モジュール」５００にて取得された「ユーザレベル機能」１０２の起動処理情報である「ユーザレベル機能起動処理情報」５０３を解析して作成する。

「解析モジュール」５０１で作成された「ブロック条件」３０１−１を、「ブロックモジュール」３００から参照可能なコードに変換するモジュールを「ブロック条件コード化モジュール」５０２とする。変換された「ブロック条件」３０１−１を「コード化されたブロック条件」３０１−２とする。

以上の処理を行うことで、「コード化されたブロック条件」３０１−２を作成することが出来る。

「２．処理の再配置」
図３に示したとおり、「ＯＳ起動処理」２００において「ユーザレベル機能」１０２を「デバイス」１０１の初期化処理よりも前に実行開始するように、処理の再配置を実施する。

「３．ブロック制御によるＯＳ起動処理」
再度本実施形態の構成を確認すると、本実施形態の「ＯＳ起動処理」２００を実行する場合の全体の機能構成は、図１に示されるものである。

図１に示す通り、「カーネル」１００、「デバイス」１０１、「ユーザレベル機能」１０２、「ユーザレベル機能」１０２からの「デバイス」１０１に対しての要求をブロック／ブロック解除を実施するモジュールである「ブロックモジュール」３００、「『ブロック条件』コード化」４０２処理で作成された「コード化されたブロック条件」３０１−２がある。

「ブロックモジュール」３００は、「カーネル」１００に組み込まれている形となる。

以上で本実施形態の処理の概略の説明を終え、以下で、より詳細な説明を加える。

上述の通り、本実施形態では、最初に、図６に示した処理の流れに沿って「コード化されたブロック条件」３０１−２作成と、「カーネル」１００内への「ブロックモジュール」３００の組み込みを行うまでを実施する。以下で、処理内容の詳細について説明する。

「１．ブロック条件作成」
まず、「ユーザレベル機能」１０２の起動処理の内容と、「ユーザレベル機能」１０２の起動処理と「デバイス」１０１との処理のやり取りを情報として採取する「情報採取」４００を実施する。

この「情報採取」４００を実施する前に必要な準備として、図７で示したように「カーネル」１００に「ユーザレベル機能」１０２の起動処理の内容を把握する「情報採取モジュール」５００を「情報採取」４００を実施する前に組み込んでおく。

次に、「情報採取モジュール」５００が組み込まれている「カーネル」１００を使用したシステムにて、一度「ＯＳ起動処理」２００をテストランとして実施する。

このテストランを実施することで「情報採取モジュール」５００は、「ユーザレベル機能」１０２の起動処理の内容と、「ユーザレベル機能」１０２の起動処理と「デバイス」１０１との処理のやり取りを把握し、把握した情報を「ユーザレベル機能起動処理情報」５０３として出力する。

この「ユーザレベル機能起動処理情報」５０３は、関数レベルの詳細な情報であり、どの「ユーザレベル機能」１０２の起動処理において、どの「デバイス」１０１に対してどのような要求を出しているかという情報を含んでいる。

「ユーザレベル機能起動処理情報」５０３として出力される内容の具体的な内容を例として示す。

本具体例では、図２に示したシステムでテストランを実施した場合に取得する「ユーザレベル機能起動処理情報」５０３について説明する。

図２に示したシステムでは「デバイス」１０１はＡ、Ｂ、Ｃ、Ｄの４つ、「ユーザレベル機能」１０２は、α、β、γの３つが存在する。そして、各「デバイス」１０１と各「ユーザレベル機能」１０２は、図９（ａ）に示すような依存関係がある。図９は、本具体例におけるユーザレベル層とデバイス層の依存関係を説明するための図である。なお、図９（ｂ）は、（ａ）の依存関係を説明するための図である。図９（ａ）に示すように、αはＡを、βはＢを、γはＣを、それぞれ使用する依存関係がある。

さらに、本システムは図１０に示すようなシーケンスにて動作する。具体的な処理内容を以下＜１−１＞〜＜３−３＞として示す。

＜１−１＞
「ユーザレベル機能」１０２αの起動処理は、「デバイス」１０１Ａにあるファイルを参照する処理が存在する。

＜１−２＞
「ユーザレベル機能」１０２αの起動処理は、ａｌｐｈａ＿ｉｎｉｔ（）関数がコールされてからａｌｐｈａ＿ｓｔａｒｔｕｐ＿ｄｏｎｅ（）関数がコールされるまでの区間である。

＜１−３＞
「ユーザレベル機能」１０２αの起動処理内でａｌｐｈａ＿ｉｎｉｔ（）関数がコールされてから後に、ａｌｐｈａ＿ｄａｔａ＿ｉｎｉｔｉａｌｉｚｅ（）関数から、カーネルを介して、「デバイス」１０１にあるファイルをＯｐｅｎするｄｅｖ＿ｏｐｅｎ（）関数を、引数に対象でデバイスである「デバイス」Ａを指定しコールする。

＜２−１＞
「ユーザレベル機能」１０２βの起動処理は、「デバイス」１０１Ｂからの応答を確認する。

＜２−２＞
「ユーザレベル機能」１０２βの起動処理は、ｂｅｔａ＿ｉｎｉｔ（）関数がコールされてからｂｅｔａ＿ｓｔａｒｔｕｐ＿ｄｏｎｅ（）関数がコールされるまでの区間である。

＜２−３＞
「ユーザレベル機能」１０２βの起動処理内でｂｅｔａ＿ｉｎｉｔ（）関数がコールされてから後に、ｂｅｔａ＿ｄａｔａ＿ｉｎｉｔｉａｌｉｚｅ（）関数から、カーネルを介して、「デバイス」１０１に対して問い合わせを実施するｄｅｖ＿ｃｈｅｃｋ（）関数を、引数に対象でデバイスである「デバイス」Ｂを指定しコールする。

＜３−１＞
「ユーザレベル機能」１０２γの起動処理は、「デバイス」１０１Ｃに対して設定ファイルを書き込む処理が存在する。

＜３−２＞
「ユーザレベル機能」１０２γの起動処理はｇａｍｍａ＿ｉｎｉｔ（）関数がコールされてからｇａｍｍａ＿ｓｔａｒｔｕｐ＿ｄｏｎｅ（）関数がコールされるまでの区間である。

＜３−３＞
「ユーザレベル機能」１０２γの起動処理内でｇａｍｍａ＿ｉｎｉｔ（）関数がコールされてから後に、ｇａｍｍａ＿ｄａｔａ＿ｉｎｉｔｉａｌｉｚｅ（）関数から、カーネルを介して、「デバイス」１０１に対して設定ファイルを書き込む実施するｄｅｖ＿ｗｒｉｔｅ（）関数を、引数に対象でデバイスである「デバイス」Ｃを指定しコールする。

以上で、本実施形態の具体例のテストランにおける各処理についての説明を終える。なお、上記の関数名はすべて例である。これ以降でも関数名の記述については、本例を使用する。

上記＜１−１＞〜＜３−３＞までの処理がテストランにおいて実行されるが、このテストランにより「情報採取モジュール」５００が採取し、出力する「ユーザレベル機能起動処理情報」５０３を図１１として示す。

「ユーザレベル機能起動処理情報」５０３では、どの「ユーザレベル機能」１０２が、どの「デバイス」１０１に対して「デバイス要求」を実施するのか、という関係情報、それに加え図１０に示すシーケンス図として表すことが可能な「ユーザレベル機能」１０２の起動処理内での、どのタイミングで「デバイス」１０１に対しての「デバイス要求」行うのかという情報を関数レベルで保持する。

各「ユーザレベル機能」１０２の起動処理開始／終了については、図７に示す通り、「ユーザレベル機能」１０２を包括する形で「情報採取モジュール」５００が組み込まれているので、「情報採取モジュール」５００にて、まず「ユーザレベル機能」１０２の関数コールシーケンスを取得する。

ここで起動処理開始／終了を行う関数にそれぞれ「ＸＸＸ＿ｉｎｉｔ（）」「ＸＸＸ＿ｓｔａｒｔｕｐ＿ｄｏｎｅ（）」というプレフィックスを付けるように定めておけば、前述した関数コールシーケンスの中からそれら関数コールを見つけることで起動処理開始／終了を把握することが出来る。

また、各「ユーザレベル機能」１０２では起動処理を行うよう関数自体を定義し、その関数名を別途「情報採取モジュール」５００に通知しておいても、前記関数コールシーケンスによって、各「ユーザレベル機能」１０２での起動処理の開始／終了を把握出来る。

次に、「情報採取モジュール」５００から作成された「ユーザレベル機能起動処理情報」５０３を元に、「解析モジュール」５０１にて解析を行い、「ブロック条件」３０１−１を作成する処理である「『ブロック条件』作成」４０１を実施する。

「ブロック条件」３０１−１として出力される内容を図１２として示す。

「ブロック条件」３０１−１を作成するための「解析モジュール」５０１での解析内容は、「ユーザレベル機能起動処理情報」５０３においてどの「デバイス」１０１に対して要求つまり「デバイス要求」を行うか、という点と、対象「デバイス」１０１がどのような状態であればブロックすべきか、を中心に解析を実施する。つまり「ブロックモジュール」３００にて、「ユーザレベル機能」１０２からの「デバイス要求」に対してブロックを行うべきかどうか、という判定のための解析である。

「ユーザレベル機能起動処理情報」５０３を解析することで「ブロックモジュール」３００でのブロック実施判定に用いる「ブロック条件」３０１−１を作成する。その具体的な解析内容について以下に示す。

「解析モジュール」５０１への入力情報は、図１１で示した「ユーザレベル機能起動処理情報」５０３と、図１３に示した「デバイス要求継続条件」５０４とする。なお、図１３は、デバイス状態管理テーブルの一例を示す図であるが、デバイス状態管理テーブルの詳細については後述する。

「デバイス要求継続条件」５０４とは、「デバイス要求」としてコールされる関数名と、その該当関数が処理を行うのに必要な「デバイス」１０１の状態、つまり図１３に示した「デバイス」１０１の状態でなければ、「デバイス要求」は失敗する、という情報を表している。「デバイス」１０１の状態としては、以下に詳述する「ＲＵＮＮＩＮＧ」と「ＮＯＴＲＥＡＤＹ」の2つを含む、種々の状態がある。

「ＲＵＮＮＩＮＧ」とは、該当「デバイス」１０１が起動処理を終えて、「デバイス要求」に応じた処理が可能な状態であること表す。

「ＮＯＴＲＥＡＤＹ」とは、該当「デバイス」１０１が起動処理をまだ終えておらず、「デバイス要求」に応じた処理が出来ない状態を表す。

「デバイス要求継続条件」５０４では、デバイス要求関数毎にその要求が処理出来るデバイスの状態を示すが、どのようなデバイスの状態であっても良い場合は「ａｎｙ」で表す。つまり「デバイス」１０１がどのような状態であっても該当の「デバイス要求」を受け付けることが可能であることを示す。

したがって、図１３からは、前述した「ユーザレベル機能起動処理情報」５０３から、「ユーザレベル機能」１０２αからの「デバイス」１０１Ａに対する「デバイス要求」として、「ユーザレベル機能」１０２αのａｌｐｈａ＿ｄａｔａ＿ｉｎｉｔｉａｌｉｚｅ（）関数から「デバイス」１０１Ａに対してｄｅｖ＿ｏｐｅｎ（）関数がコールされることが分かる。

また、ｄｅｖ＿ｏｐｅｎ（）は、「デバイス要求継続条件」５０４から、「デバイス」１０１Ａの初期化処理が完了する前の状態、つまり「デバイス」１０１Ａがそれを示す「ＮＯＴＲＥＡＤＹ」状態の場合、処理が出来ないことが分かる。つまり「ユーザレベル機能」１０２αからの「デバイス」１０１Ａに対しての「デバイス要求」であるｄｅｖ＿ｏｐｅｎ（）関数コールは、「デバイス」１０１Ａが「ＲＵＮＮＩＮＧ」状態でなければ、その関数コールは失敗する。

よって、「ユーザレベル機能」１０２αからの「デバイス」１０１Ａに対しての「デバイス要求」であるｄｅｖ＿ｏｐｅｎ（）関数コールは、「デバイス」１０１Ａが「ＲＵＮＮＩＮＧ」状態になるまで、つまり「ＮＯＴＲＥＡＤＹ」の状態であれば「デバイス要求」をブロックする必要があることが分かる。

同様に、「ユーザレベル機能」１０２βからの「デバイス」１０１Ｂに対する「デバイス要求」として、「ユーザレベル機能」１０２βのｂｅｔａ＿ｄａｔａ＿ｉｎｉｔｉａｌｉｚｅ（）関数から、「デバイス」１０１Ｂに対してｄｅｖ＿ｃｈｅｃｋ（）関数がコールされるが、ｄｅｖ＿ｃｈｅｃｋ（）関数は、「デバイス要求継続条件」５０４から「デバイス」１０１Ｂの初期化処理が完了する前の状態つまり「デバイス」１０１Ｂがそれを示す「ＮＯＴＲＥＡＤＹ」状態である場合、処理が失敗するので、「ＲＵＮＮＩＮＧ」状態で無ければ「デバイス要求」をブロックしなければならないことが解析により把握可能である。

また、「ユーザレベル機能」１０２γのｇａｍｍａ＿ｄａｔａ＿ｉｎｉｔｉａｌｉｚｅ（）関数からの、「デバイス」１０１Ｃに対する「デバイス要求」も同様に、「デバイス」１０１Ｃへのｄｅｖ＿ｗｒｉｔｅ（）関数は、「デバイス要求継続条件」５０４から「デバイス」１０１Ｃの初期化処理が完了する前の状態つまり「デバイス」１０１Ｃがそれを示す「ＮＯＴＲＥＡＤＹ」状態である場合、処理が失敗するので、「ＲＵＮＮＩＮＧ」状態で無ければ「デバイス要求」をブロックしなければならないことが解析により把握可能である。

「ブロック条件作成」ステップＳ４０２は、上記のような「解析モジュール」５０１での解析により、「ブロック条件」３０１−１を作成する処理である。

「デバイス」１０１の状態は、例えば「カーネル」１００内に存在する「デバイス状態管理テーブル」を参照することで把握する。この「カーネル」１００内に存在する「デバイス状態管理テーブル」の例を図１３として示す。

また、「デバイス」１０１から「ブロックモジュール」３００に対して「デバイス」１０１自身の状態変化を通知させても良い。さらに「ブロックモジュール」３００が「デバイス」１０１に対して状態を問い合わせる方法でも良い。

「ブロック条件」３０１−１としては図１２に示した通り、例えば、次の５点の情報を保持している。
・どの「ユーザレベル機能」１０２からの「デバイス要求」なのか
・どの「ユーザレベル機能」１０２のどの関数からコールされるのか
・どの「デバイス」１０１に対しての「デバイス要求」なのか
・「デバイス」１０１の、どの関数が使用されるのか
・「デバイス」１０１がどのような条件であれば「デバイス要求」をブロックする必要があるのか

次に「カーネル」１００に組み込む予定の「ブロックモジュール」３００から「ブロック条件」３０１−１を参照出来るように、「ブロック条件」３０１−１をコード化する「『ブロック条件』コード化」ステップＳ４０２を実施する。

「『ブロック条件』コード化」ステップＳ４０２とは、「ブロックモジュール」３００から「ブロック条件」３０１−１を参照可能とするために、「ブロック条件」３０１−１に対して「ブロックモジュール」３００が動作時に解釈出来るデータ形式に変換することである。

このコード化された「ブロック条件」３０１−１である、「コード化されたブロック条件」３０１−２の例を図１４に示す。

図１４に示した、「コード化されたブロック条件」３０１−２は、カーネルコードに組み込んでも良いが、カーネルコードとは別にシステム上の適切な場所、例えば、
・「カーネル」１００から参照可能な、システムに搭載されているメモリ上
・「カーネル」１００から参照可能な、システムに搭載されている「カーネル」１００のソースコードが格納されているＲＯＭ上
といった場所に「コード化されたブロック条件」３０１−２を格納しても良い。

以上より、「コード化されたブロック条件」３０１−２の作成を完了する。

「２．処理の再配置」
次に、「ユーザレベル機能」１０２の起動処理の再配置を実施する。

ユーザに対しての「ユーザレベル機能」１０２の提供を早期化するためには、最初に「ユーザレベル機能」１０２の起動処理完了タイミングを早める必要がある。

これは図３に示した通り、「ＯＳ起動処理」２００において「ユーザレベル機能」１０２の起動処理開始タイミングを早めることにより実現する。

具体的には、「ユーザレベル機能」１０２の開始ポイントである関数コールを「デバイス」１０１の初期化処理以前にコールするようにコードを再配置する。

再配置を実施する前の「ＯＳ起動処理」２００の処理順序を図１５に示す。再配置を実施した後の「ＯＳ起動処理」２００の処理順序は図３で示した通りである。

以上により「ＯＳ起動処理」２００を実施する準備が出来た。以下で、「ＯＳ起動処理」２００における「ブロック手段」「ブロック解除手段」の詳細な動作について説明する。

「３．ブロック制御によるＯＳ起動処理」
「ブロックモジュール」３００での「ブロック手段」の処理内容について図１６に、「ブロックモジュール」３００での「ブロック解除手段」の処理内容について図１７、ブロックしている「デバイス要求」を管理する「ブロックリスト」を図１８に示す。

まず「ブロック手段」の詳細な動作について図１６に沿って説明する。

「ユーザレベル機能」１０２からの「デバイス要求」が「ブロックモジュール」３００を介して実行される。「ブロックモジュール」３００は、「デバイス要求」を受け（ステップＳ１６０１）、「ブロック条件」３０１−１である「コード化されたブロック条件」３０１−２を参照し、該当「デバイス」１０１の現在の状態と比較することで、その「デバイス要求」を継続しても問題無いかどうかを判定する（ステップＳ１６０２）。

ここで「コード化されたブロック条件」３０１−２に合致しない「デバイス」１０１の状態であれば（ステップＳ１６０２、Ｎｏ）、「ユーザレベル機能」からの「デバイス要求」をブロックすること無く「デバイス要求」を該当「デバイス」１０１に対して送る（ステップＳ１６０３）。

しかし、「コード化されたブロック条件」３０１−２に合致する「デバイス」１０１の状態であれば（ステップＳ１６０２、Ｙｅｓ）、ブロックしている「デバイス要求」を「ブロックリスト」に追加し（ステップＳ１６０４）、その「デバイス要求」をブロックする（ステップＳ１６０５）。

この「デバイス要求」のブロックとは、「デバイス要求」を継続しないようにすることであり例えば「デバイス要求」を行ったスレッドをＳｌｅｅｐさせたり、Ｗａｉｔさせたりすることでも良い。

具体的な内容としては、例えば、「ユーザレベル機能」１０２αのａｌｐｈａ＿ｄａｔａ＿ｉｎｉｔｉａｌｉｚｅ（）関数から、「ブロックモジュール」３００を介して「デバイス」１０１Ａに対してｄｅｖ＿ｏｐｅｎ（）関数がコールされるが、「ブロックモジュール」３００は「コード化されたブロック条件」３０１−２を参照し、「デバイス」１０１Ａの状態が初期化処理を終えていないことを示す「ＮＯＴＲＥＡＤＹ」の場合、「ユーザレベル機能」１０２αからの「デバイス要求」を「ブロックモジュール」３００はブロックし、「ブロックリスト」にブロックした「デバイス要求」の内容を追加する。

また、「デバイス」１０１Ａの状態が初期化処理を終えたことを示す「ＲＵＮＮＩＮＧ」の場合には、「ユーザレベル機能」１０２αからの「デバイス要求」を「ブロックモジュール」３００はブロックすること無く、「デバイス」１０１Ａに対してｄｅｖ＿ｏｐｅｎ（）関数をコールする。

「ユーザレベル機能」１０２からの「デバイス要求」をブロックした場合の、「ＯＳ起動処理」２００の処理の流れを図１９に示す。

次に、「ブロック解除手段」の詳細な動作について図１７に沿って説明する。

「ブロックモジュール」３００はある一定期間の間隔をおいて、定期的に図１８で示したような「ブロックリスト」を参照する（ステップＳ１７０１）。若しくは「デバイス」１０１から初期化終了などの状態変化時に、状態変更通知を受けてから「ブロックリスト」を参照する形でも良い。

ここで、リスト上に「デバイス要求」をブロックしていることを示す情報があれば（ステップＳ１７０２、Ｙｅｓ）、「デバイス」１０１の現在の状態を確認した上で（ステップＳ１７０３）、「コード化されたブロック条件」３０１−２を参照し、「コード化されたブロック条件」３０１−２に合致しない「デバイス」１０１の状態であれば（ステップＳ１７０４、Ｎｏ）、ブロックリストからデバイス要求情報を削除した上で（ステップＳ１７０５）、ブロックしている「デバイス要求」を該当「デバイス」１０１に対し送信する（ステップＳ１７０６）。

リスト上に「デバイス要求」をブロックしていることを示す情報があるが、該当「デバイス」１０１の状態を確認した際、「コード化されたブロック条件」３０１−２に合致しない「デバイス」１０１の状態でなければ（ステップＳ１７０４、Ｙｅｓ）、「ブロックモジュール」３００は、「ブロック解除手段」を行わない（ステップＳ１７０７）。

ブロック解除を実行する又は実行しない場合のいずれであっても、再度ブロックリストの次のデバイス要求を取得する（ステップＳ１７０８）。

具体的な内容としては、「ユーザレベル機能」１０２αからの「デバイス要求」をブロックしていたことを示す情報が「ブロックリスト」に存在した場合、「ブロックモジュール」３００は、「デバイス」１０１Ａの状態が「ＮＯＴＲＥＡＤＹ」から初期化処理を終えたことを示す「ＲＵＮＮＩＮＧ」に状態が変更していれば、その「デバイス要求」をブロックリストから外し、ブロックしていた「ユーザレベル機能」１０２αからの「デバイス要求」を該当「デバイス」１０１に送信する。

このように、「ブロックモジュール」３００は、「ユーザレベル機能」１０２の起動処理からの「デバイス要求」をブロック／ブロック解除を実施することで、「ＯＳ起動処理」２００において「ユーザレベル機能」１０２の起動処理開始タイミングを早めても、「ユーザレベル機能」１０２の起動処理が問題無く完了するよう、制御を実施する。

この制御により、「ユーザレベル機能」１０２の起動処理完了タイミングを早くすることが可能となる。よって「ユーザレベル機能」１０２として機能提供可能状態が早まることで、ユーザに対しての「ユーザレベル機能」１０２の提供が早期化されることが実現可能となる。

「情報採取」４００、「『ブロック条件』作成」４０１、「『ブロック条件』コード化」４０２という処理を実施し、解決手段の第１から３の構成要素を用いることで本実施形態として「ブロックモジュール」３００によるブロック／ブロック解除制御が可能となり、ユーザに対しての「ユーザレベル機能」１０２提供の早期化を実現することが可能となる。

ユーザに対しての「ユーザレベル機能」１０２提供の早期化を実現出来た「ＯＳ起動処理」２００と、「ユーザレベル機能」１０２提供の早期化を実現する前の「ＯＳ起動処理」２００との比較を表したタイミングチャート図を図２０として示す。

また、本発明を実施しユーザに対しての「ユーザレベル機能」１０２提供の早期化を実現出来た「ＯＳ起動処理」２００のシーケンスを図２１に示す。

以上で、本実施形態の構成及び動作の説明を終え、以下で、本実施形態の効果について説明する。本実施形態の効果は、少なくとも、下記の第１から５の５つの効果が挙げられる。

・第１の効果は、ユーザに対して「ユーザレベル機能」１０２の提供タイミングを早期化出来る点にある。

従来では、ユーザに対しての「ユーザレベル機能」１０２提供のタイミングは「ＯＳ起動処理」２００としての後半、つまりシステムとして電源が投入され、その後に実行されるシステムに搭載されているすべての「デバイス」１０１の初期化処理が完了した後であったが、「ユーザレベル機能」１０２の起動処理において実施される、「デバイス」１０１に対しての処理の要求において、予め作成した条件に従いブロック／ブロック解除を実施しＯＳ起動処理全体の処理順序を制御することで、システムを利用するユーザに対しての機能提供タイミングを早期化することが出来る。

・第２の効果は、「ユーザレベル機能」１０２の起動処理の開始タイミングを早めることが出来る点にある。

従来では、システムに搭載されているすべての「デバイス」１０１の初期化処理が完了した後に「ユーザレベル機能」１０２の起動処理を行っていた。また、「デバイス」１０１の種類によっては初期化処理に掛かる時間が長いものも存在した。その上「ユーザレベル機能」１０２によってはそのような初期化処理に時間が掛かる「デバイス」１０１を必要としない場合もあり、すべての「デバイス」１０１の初期化処理が完了するまで「ユーザレベル機能」１０２の起動処理を開始しないという処理順序であった。しかし、「ユーザレベル機能」１０２の提供に必要な「デバイス」１０１のみ初期化処理を行い、「ユーザレベル機能」１０２の提供に必要としない「デバイス」の初期化処理を「ユーザレベル機能」１０２の提供後に実行することで、従来の処理順序より「ユーザレベル機能」１０２の起動処理の開始タイミングを早めることが出来る。

・第３の効果は、システムを使用するユーザに対して「ユーザレベル機能」１０２の提供を早期化するため、「ユーザレベル機能」１０２の起動処理を「デバイス」１０１の初期化より前に実施しても問題が生じず「ユーザレベル機能」１０２の起動処理が完了出来る点にある。

「ブロックモジュール」３００が「デバイス」１０１に対する要求である「デバイス要求」を「ブロック条件」３０１−１に従い適切にブロック／ブロック解除をすることで、「ユーザレベル機能」１０２の起動処理の前倒しを実施しても矛盾が生じること無く「ユーザレベル機能」１０２の起動処理が完了することが可能となり、「ユーザレベル機能」１０２提供の早期化を実現出来る。

・第４の効果は、人の手によって行うユーザに対しての「ユーザレベル機能」１０２の提供を早期化する方法では、生じてしまう可能性がある問題を確実に回避することが可能な点にある。

人の手によって行うユーザに対しての「ユーザレベル機能」１０２の提供を早期化する手段では、「ユーザレベル機能」１０２の起動処理をすべて詳細にソースコードレベルで把握した上で行う必要があり、その上、人の手では見落としや処理順序の矛盾が発生しやすいが、本発明では「ユーザレベル機能」１０２の起動処理をすべて把握する必要は無く、1回の「カーネル起動処理」１００のテストラン実施を行うだけで、「ユーザレベル機能」１０２提供の早期化が可能となり、人の手によって行うより見落としや処理順序の矛盾が発生しない。

・第５の効果は、システムの高機能化が進み搭載「デバイス」１００数と搭載「ユーザレベル機能」１０２が増加しても、「ユーザレベル機能」１０２の提供を早期化することが可能な点にある。

システムに要求される高機能化により搭載「デバイス」１００数と搭載「ユーザレベル機能」１０２数が増加した場合でも、本発明は「デバイス」１００数や「ユーザレベル機能」１０２数に依存した手段を用いておらず、「デバイス」１００と「ユーザレベル機能」１０２との処理内容の相関を解析に用いるため、搭載数が増加した場合も確実に「ユーザレベル機能」１０２の提供を早期化することが可能である。

本発明により、ユーザに対して「ユーザレベル機能」の提供を早期化することが可能となるため、任意のデバイスを搭載し、ユーザに対して何らかの機能を提供するシステム全般に適用可能である。

本発明による実施形態の機能構成を示す図である。 本実施形態の階層構成を説明するための図である。 本実施形態によるＯＳ起動処理の再配置を説明するための図である。 本実施形態によるブロック手段を説明するための図である。 本実施形態によるブロック解除手段を説明するための図である。 本実施形態のブロック条件作成のための３つの処理を説明するための図である。 本実施形態のブロック条件作成に必要なモジュールを説明するための図（その１）である。 本実施形態のブロック条件作成に必要なモジュールを説明するための図（その２）である。 本実施形態の具体例におけるユーザレベル層とデバイス層の依存関係を説明するための図である。 本実施形態の具体例の動作例を示すシーケンス図である。 本実施形態の具体例の「ユーザレベル機能起動処理情報」５０３の一例を示す図である。 本実施形態の具体例の「ブロック条件」３０１−１として出力される内容の一例を示す図である。 本実施形態の具体例のデバイス状態管理テーブルの一例を示す図である。 本実施形態の具体例の「コード化されたブロック条件」３０１−２の一例を示す図である。 本実施形態の具体例の起動処理の再配置を実施する前の状態を説明するための図である。 本実施形態のブロックモジュール３００によるブロック処理の手順を示すフローチャート図である。 本実施形態のブロックモジュール３００によるブロック解除処理の手順を示すフローチャート図である。 本実施形態の具体例によるブロックリストの一例を示す図である。 本実施形態の具体例によるユーザレベル機能からのデバイス要求をブロックした場合のＯＳ起動処理の処理の流れを示す図である。 本実施形態の具体例によるＯＳ起動処理のタイミングチャート図である。 本実施形態の具体例によるＯＳ起動処理のシーケンス図である。 従来の情報処理装置の、各デバイスを含めてＯＳの機能構成を説明するための図である。 従来の情報処理装置の、ＯＳ起動処理の流れを説明するための図である。

符号の説明

１００ カーネル
１０１ デバイス
１０２ ユーザレベル機能
２００ ＯＳ起動処理
２０１ カーネル起動処理
２０２ ユーザレベル機能起動処理群
３００ ブロックモジュール
３０１−１ ブロック条件
３０１−２ コード化されたブロック条件
５００ 情報採取モジュール
５０１ 解析モジュール
５０２ ブロック条件コード化モジュール
５０３ ユーザレベル機能起動処理情報
５０４ デバイス要求継続条件

Claims (6)

1. オペレーティングシステムを格納する記憶手段を有する情報処理装置の起動方法であって、
   前記オペレーティングシステムのカーネルに組み込まれたブロックモジュールが、前記カーネルの行う前記情報処理装置の各デバイスの初期化処理を、前記ブロックモジュールの記憶するブロック条件に基づいて、実行させないブロック処理と、
   該ブロック処理の後、前記ブロックモジュールが、前記オペレーティングシステムの提供するユーザレベル機能を、前記カーネルに起動させるユーザレベル機能起動処理と、
   該ユーザレベル起動処理の後、前記カーネルが、前記各デバイスの初期化を行うデバイス初期化処理と、
   を有することを特徴とする情報処理装置の起動方法。
2. 前記ブロック処理により、デバイスの初期化処理が実行されなかったデバイスにつき、該デバイスから状態変化通知を受けたこと、及び、前記ブロックモジュールが定期的にデバイスの状態を参照したことのいずれか１つ以上のトリガによって、前記カーネルが、前記デバイスのブロックを解除するブロック解除処理を有することを特徴とする請求項１記載の情報処理装置の起動方法。
3. 前記ユーザレベル機能と前記各デバイスとの処理のやり取りを、情報として採取する情報採取処理を有し、
   前記ブロック条件は、前記情報採取処理に基づいて作成することを特徴とする請求項１又は２記載の情報処理装置の起動方法。
4. 前記ブロック条件は、情報処理装置の各デバイスの構成に変更があった際に、条件の入れ替えが実行されることを特徴とする請求項１から３のいずれか１項記載の情報処理装置の起動方法。
5. オペレーティングシステムを格納する記憶手段を有する情報処理装置であって、
   前記オペレーティングシステムのカーネルに組み込まれたブロックモジュールと、
   該ブロックモジュールが記憶するブロック条件と、を有し、
   前記カーネルは、前記情報処理装置の起動処理の際、
   前記ブロック条件に基づいて、前記情報処理装置の各デバイスの初期化処理を、前記ブロック条件がブロックするデバイスについては実行させず、
   前記ブロックモジュールは、前記オペレーティングシステムの提供するユーザレベル機能を、前記各デバイスの初期化処理に先立ってユーザに提供するよう、前記オペレーティングシステムの起動処理の再配置を実行することを特徴とする情報処理装置。
6. オペレーティングシステムを格納する記憶手段を有する情報処理装置に前記オペレーティングシステムの起動処理を実行させる起動プログラムであって、
   前記情報処理装置に、
   前記オペレーティングシステムのカーネルに組み込まれたブロックモジュールが、前記カーネルの行う前記情報処理装置の各デバイスの初期化処理を、前記ブロックモジュールの記憶するブロック条件に基づいて、実行させないブロック処理と、
   該ブロック処理の後、前記ブロックモジュールが、前記オペレーティングシステムの提供するユーザレベル機能を、前記カーネルに起動させるユーザレベル機能起動処理と、
   該ユーザレベル起動処理の後、前記カーネルが、前記各デバイスの初期化を行うデバイス初期化処理と、
   を実行させることを特徴とする起動プログラム。

Images