(57)【要約】      （修正有）【課題】サーバの複数の内部レジスタにアクセスする方法において、外部ユーザによるサーバの内部レジスタへのアクセスを容易にする。【解決手段】外部ユーザからのアクセスコマンドを、１つ以上のアクセスプロトコル６１〜６３を用いて内部レジスタ７４にアクセスするサービスプロセッサ８２が直接的に理解可能な通信プロトコルＩＰＭＩを用いてサービスプロセッサ８２に送信し、外部ユーザによって発行されたコマンドライン１１を、少なくとも内部レジスタ７４の対応するアドレスと外部ユーザから供給される内部レジスタ７４の名前とを関連付ける１つ以上のサービスモジュール３０を用いて、通信プロトコルＩＰＭＩでのアクセスコマンドに自動変換する。【選択図】図１
2016004587.tif 000002
【特許請求の範囲】
【請求項１】
サーバ（８３）の複数の内部レジスタ（７４）にアクセスする方法であって、
前記サーバ（８３）の外部ユーザからのアクセスコマンドを前記サーバ（８３）のサービスプロセッサ（８２）に、前記サービスプロセッサ（８２）が直接的に理解可能な通信プロトコル（ＩＰＭＩ）を用いて送信することと、
前記内部レジスタ（７４）にアクセスするのに１つ以上のアクセスプロトコル（６１〜６３）を用いて、前記サービスプロセッサ（８２）によって前記内部レジスタ（７４）にアクセスすることと、
１つ以上のサービスモジュール（３０）によって、前記外部ユーザが発行したコマンドライン（１１）を前記通信プロトコル（ＩＰＭＩ）でのアクセスコマンドに自動変換することとを含み、
前記コマンドライン（１１）の言語（Ｐｙｔｈｏｎ）は前記通信プロトコル（ＩＰＭＩ）のものよりも高レベルのものであり、前記１つ以上のサービスモジュール（３０）は前記コマンドライン（１１）に含まれる前記内部レジスタ（７４）の名前を、少なくとも前記アクセスコマンドにおける前記内部レジスタ（７４）の対応するアドレスにマッピングし、
前記サービスプロセッサ（８２）から前記内部レジスタ（７４）への前記外部ユーザによって指令されるアクセスの際は、前記内部レジスタ（７４）のステータスのコピーを更新する目的での前記サービスプロセッサ（８２）の直接制御下での前記内部レジスタ（７４）への監視アクセスとの衝突のリスクの可能性を前記サービスプロセッサ（８２）が処理することを特徴とするサーバの複数の内部レジスタにアクセスする方法。
【請求項２】
前記１つ以上のサービスモジュール（３０）は、前記コマンドライン（１１）に含まれる前記内部レジスタ（７４）の名前と、さらに前記アクセスコマンドにおける前記内部レジスタ（７４）に対応するアドレス形式にも関連していることを特徴とする請求項１に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項３】
前記サービスモジュール（３０）の少なくとも１つが、名前、前記内部レジスタ（７４）の対応するアドレスに関連している前記内部レジスタ（７４）の前記名前のリストを含み、前記リストは好ましくは前記外部ユーザによってアクセスされ得る全ての前記内部レジスタ（７４）を備え、前記サーバ（８３）の構成毎に、前記リストが更新されることを特徴とする請求項１または請求項２に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項４】
前記リストは、また、前記名前及び前記アドレス、前記内部レジスタ（７４）の全てのビット（７５）の説明と関連していることを特徴とする請求項３に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項５】
前記衝突のリスクは、中断されることのない前記監視アクセスの進行の全ての段階中に前記外部ユーザによって制御される前記アクセスを保留させることで回避することを特徴とする請求項１〜４のいずれか１項に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項６】
前記監視アクセスの前記進行は、前記サービスプロセッサ（８２）と前記内部レジスタ（７４）との間に位置するマルチプレクサを再構成することと前記内部レジスタ（７４）の少なくとも１つを読み出すことのうちの１つの連続を少なくとも含むことを特徴とする請求項５に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項７】
前記コマンドライン（１１）は、１つ以上のスクリプト（１２）にグループ分けすることができることを特徴とする請求項１〜６のいずれか１項に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項８】
前記コマンドライン（１１）は、前記外部ユーザに、アクセスされる前記内部レジスタ（７４）の名前を、そのアドレス、そのアドレス形式、及びそのアクセスモードを除外して供給することのみを要求することを特徴とする請求項１〜７のいずれか１項に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項９】
前記外部ユーザからの前記コマンドライン（１１）の１つに反応して、前記内部レジスタ（７４）のビット（７５）の値がこれらのビット（７５）に対応するフィールド名と共に表示されることを特徴とする請求項１〜８のいずれか１項に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項１０】
前記コマンドライン（１１）の言語が、Ｐｙｔｈｏｎであることを特徴とする請求項１〜９のいずれか１項に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項１１】
前記通信プロトコルは、ＩＰＭＩプロトコルであることを特徴とする請求項１〜１０のいずれか１項に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項１２】
前記ＩＰＭＩ通信プロトコルが、イーサネット（登録商標）バス上で実行されることを特徴とする請求項１１に記載のサーバの複数の内部レジスタにアクセスする方法。
【請求項１３】
前記内部レジスタ（７４）は、前記サーバの１つ以上のコンポーネント（７１〜７３）、前記コンポーネント（７１〜７３）の１つであり得る１つ以上のＣＰＵ、及び／または１つ以上のＡＳＩＣ、及び／または１つ以上のＦＰＧＡに属することを特徴とする請求項１〜１２のいずれか１項に記載のサーバの複数の内部レジスタにアクセスする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバの複数の内部レジスタにアクセスする方法に関する。
【背景技術】
【０００２】
従来、サーバの複数の内部レジスタにアクセスする方法としては、サーバの外部ユーザが、サービスプロセッサによって直接理解可能な通信プロトコルで、そのサーバの内部レジスタへのアクセスを処理するサービスプロセッサにアクセスコマンドを直接供給することが知られている。
【先行技術文献】
【特許文献】
【０００３】
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところが、従来のサーバの複数の内部レジスタにアクセスする方法では、外部ユーザは、内部レジスタの種類だけではなく、アドレスまたはさらにはそのコンテンツ若しくはアドレス指定形式を通信プロトコルと併せて習得する立場でいなければならない。これは、これらの内部レジスタへのアクセスを外部ユーザにとっていくらか難しくする。
さらに、平均的な外部ユーザは、この情報の全てを完全に制御することができないために、エラーのリスクは無視できない。
【０００５】
そこで、本発明の目的は、上述の欠点を少なくとも部分的に解消させることができるサーバの内部レジスタにアクセスする方法を提供することである。
【課題を解決するための手段】
【０００６】
具体的には、本発明は、第１に、外部ユーザがサービスプロセッサによって直接的に理解可能な通信プロトコルの具体的な知識を必要とせず、第２に、外部ユーザが上記内部レジスタの構造及びそれらのサーバにおける実施についての具体的な知識を必要としない、サーバの内部レジスタにアクセスする方法を提供することを目的とする。この外部ユーザによるこれらの内部レジスタへのアクセスをより人間工学的及びより安全にすること、言い換えると、内部レジスタへのそのアクセスは、より容易になり、排除されるか少なくとも大きく低下したエラーのリスクを提示する。
【０００７】
このため、本発明は、外部ユーザによる内部レジスタにアクセスする難しい性質、及び通信プロトコルまたは上記内部レジスタの構造及び実施の専門家でない外部ユーザに内部レジスタにアクセス可能とさせる特定の関心を強調した後に、システムのより高層または高層の複数の層に送られる上記内部レジスタの構造及び実施についての情報を同時に提供し、その高層またはそれらの複数の高層では、この通信プロトコルに比較的高レベル言語におけるコマンドを翻訳する手段を提供する。
【０００８】
この情報を高層または複数の高層に送ること、及び翻訳手段の実施は、本発明が外部ユーザに与える、一見すると重要であるが、サーバの内部レジスタへのアクセスの流動性及び容易性によって大きく有益となるシステム改変努力を表し、エラー、特に内部レジスタの間違ったアドレス指定に関するリスクの実質的な減少も言うまでもない。
【０００９】
この目的を得るべく、本発明は、サーバの複数の内部レジスタにアクセスする方法を提供し、前記サーバの外部ユーザからのアクセスコマンドを前記サーバのサービスプロセッサに、前記サービスプロセッサが直接的に理解可能な通信プロトコルを用いて送信することと、前記内部レジスタにアクセスするのに１つ以上のアクセスプロトコルを用いて、前記サービスプロセッサによって前記内部レジスタにアクセスすることと、１つ以上のサービスモジュールによって、前記外部ユーザが発行したコマンドラインを前記通信プロトコルでのアクセスコマンドに自動変換することとを含み、前記コマンドラインの言語は前記通信プロトコルのものよりも高レベルのものであり、前記１つ以上のサービスモジュールは前記コマンドラインに含まれる前記内部レジスタの名前を、少なくとも前記アクセスコマンドにおける前記内部レジスタの対応するアドレスにマッピングし、前記サービスプロセッサから前記内部レジスタへの外部ユーザによって指令されるアクセスの際は、前記内部レジスタのステータスのコピーを更新する目的での前記サービスプロセッサの直接制御下での前記内部レジスタへの監視アクセスとの衝突のリスクの可能性を前記サービスプロセッサが処理することを特徴とする。
【００１０】
サーバの内部レジスタへのアクセスは、読出しアクセスまたは書込みアクセスである。サーバの内部レジスタは、メモリから区別される、サーバの計算コンポーネントの内部レジスタであって、サーバは、計算コンポーネントとメモリとを備える。通信プロトコルの専用の性質及び内部レジスタに関連する情報の比較的隠されたまたは埋没された性質は、システムの最も高い層への移動を前もって仕掛けるわけではない。
【００１１】
外部ユーザによって指令される、サービスプロセッサによる内部レジスタへの前記アクセスの間、前記内部レジスタのステータスのコピーを更新するための前記サービスプロセッサによって直接的に指令される前記内部レジスタへの監視アクセスとの衝突のリスクの可能性は、サービスプロセッサによって処理される。よって、サービスプロセッサは、内部レジスタにアクセスするための、監視プロセスからの１つと同様に外部ユーザからの要求の両方の種類を直接的に受け取った後に、そのレベルにおいて、衝突のリスクを処理することができ、結果としてより容易に除去することができる。
【００１２】
この目的を得るべく、本発明は、また、サーバの複数の内部レジスタにアクセスするための、サーバの外部の外部ユーザからのアクセスコマンドをサーバのサービスプロセッサに送信するように適合される、前記サービスプロセッサから前記内部レジスタにアクセスするための前記サービスプロセッサによって直接的に理解可能な通信プロトコルを用いて、１つ以上のアクセスプロトコルを前記内部レジスタに用いるユーザインターフェースを提供し、前記外部ユーザによって発行されたコマンドラインを前記通信プロトコルにおける前記アクセスコマンドに自動変換するように適合される、前記コマンドラインの言語が前記通信プロトコルのものよりも高いレベルのものであり、前記コマンドラインに含まれる前記内部レジスタの名前、少なくとも前記アクセスコマンドにおける前記内部レジスタの対応するアドレスに関連付けるための１つ以上のサービスモジュールを備えることを特徴とする。
【００１３】
本発明の実施形態によれば、結果的には、外部ユーザに対してサーバの計算コンポーネントの内部レジスタに読み出すまたは書き込むための単純なアクセス方法を提供するようになっている。
【００１４】
本発明の好ましい実施形態によれば、結果的には、計算コンポーネントの内部レジスタを読み出す及び書き込めるように、並びに外部ユーザにＰｙｔｈｏｎモジュールを提供することでスクリプトを書き込む能力を与えるように、コマンドラインインターフェースを提供するようになっている。
【００１５】
本発明の実施形態によれば、これらのアクセスを機械に、機械が動作中であっても行うようになっている。
【００１６】
本発明の実施形態によれば、それらの名前、アドレス及びコンテンツの説明を含む全ての内部レジスタの完全なリストを生成して、外部ユーザから隠れる、言い換えれば、外部ユーザにとって全てまたは一部が透明となるようになっている以下を含む要素：これらレジスタへのアクセス方法、機械が動作中であるという事実によるこれらのレジスタへの同時アクセスの問題、レジスタのアドレス及びサーバの動力ステータスのモジュールを有するスクリプト言語、を提供する。
【００１７】
望ましい実施形態によれば、本発明は、別々に用いられるか部分的または完全にそれらの間で組み合わせて、特に上記の構成要素の１つと共に用いることができる以下の特徴の１つ以上を備える。
【００１８】
好ましくは、前記１つ以上のサービスモジュールは、前記コマンドラインに含まれる前記内部レジスタの名前、及び前記アクセスコマンドにおける前記内部レジスタに対応するアドレス形式に関連付けられる。よって、内部レジスタにサービスプロセッサをアクセスさせることを許可する全ての関連する情報がアクセスコマンドに組み込まれ、別の追加ステップに加えられる必要がない。
【００１９】
好ましくは、前記サービスモジュールの少なくとも１つは、前記名前に関連付けられる前記内部レジスタの名前、前記内部レジスタの対応するアドレスのリストを含み、前記リストは前記外部ユーザによってアクセスし得る全ての前記内部レジスタを好ましくは備え、各サーバ構成にて、このリストは更新される。各サーバ構成での内部レジスタのリストの更新は、いかなるときであれ関心を持たれ得る全ての内部レジスタに外部ユーザによるアクセスを保証するので特に有利であり、ある所定の時点であっても、内部レジスタの構成または実施は改変される。これに該当しない場合、このような改変の際は、この内部レジスタの改変のための更新動作が他で行われるまで内部レジスタにアクセスすることができなかった。
【００２０】
好ましくは、前記リストは、前記名前及び前記アドレス、前記内部レジスタの全ての部分の説明とも関連付けられる。結果として、外部ユーザに内部レジスタへのアクセスが保証されるだけではなく、特定のビットを変更するか分析するなどの細かい動作なども行うことが可能となる。
【００２１】
好ましくは、前記衝突のリスクは、前記外部ユーザによって指令される前記アクセスを、中断されない前記監視アクセス進行中の全ての段階中に静止させることで回避される。実際に、外部ユーザによって指令されるアクセスが少々遅延しても深刻な結果を招くことはないが、監視プロセスの途中に起きるよく制御されていない妨害はシステム動作を著しく劣化させる可能性がある。
【００２２】
好ましくは、前記監視アクセスの前記進行は、サービスプロセッサと前記内部レジスタとの間に位置するマルチプレクサの再構成と内部レジスタの少なくとも１つを読み出すステップとの連続を少なくとも含む。マルチプレクサの再構成と読み出しとの間に起こり得る監視プロセスの中断は、外部ユーザからの、監視プロセスによるアクセス要求のために予定された再構成を受け継ぐ別のアクセス要求であるために、著しくシステムの動作を妨害するであろう。
【００２３】
好ましくは、前記コマンドラインは、１つ以上のスクリプトにグループ分けすることができる。よって、外部ユーザによる前記内部レジスタの処理は、外部ユーザにとってより流動的となる。コマンドラインインターフェースは、外部ユーザとコンピュータとの間の通信がテキストモードで行われ、外部ユーザがテキストコマンドを打ち込んでテキスト応答を読む、人対機械のインターフェースである。スクリプトとは、コンパイルを必要とせず、単に翻訳を用いてタスクを実行することが可能なプログラムである。
【００２４】
好ましくは、コマンドラインは外部ユーザに、アクセスされる前記内部レジスタの名前を、そのアドレス、そのアドレスフォーマット、及びそのアクセスモードを除外して供給することのみを要求する。よって、外部ユーザによる前記内部レジスタの処理は、さらに外部ユーザにとって容易となる。
【００２５】
好ましくは、外部ユーザからのコマンドラインの１つに反応して、前記内部レジスタのビット値が、これらのビットと対応するフィールドの名前と一緒に表示される。よって、外部ユーザは、各内部レジスタについてビット毎に、そのコンテンツが探している情報と一致することを認証することができる。この追加されたセキュリティによって、外部ユーザは、以前に注意を引かなかったり外部ユーザの注意から漏れていたりした内部レジスタの構成の変更に直ちに気づくことができ、または、必要に応じて内部レジスタの細かい構成を行うことができる。
【００２６】
好ましくは、前記コマンドラインの言語は、Ｐｙｔｈｏｎ言語である。この言語は、外部ユーザにとって、サーバの内部レジスタの処理について特に単純及び流動的である。Ｐｙｔｈｏｎは、周知の高レベルプログラミング言語であり、コマンドラインについて構文が限られており、特にスクリプトコンテクストにおいて有効である。
【００２７】
好ましくは、前記通信プロトコルは、ＩＰＭＩプロトコルである。この通信プロトコルは、サーバの内部レジスタ上の予定された動作を行うのに特に有効である。ＩＰＭＩ（「Ｉｎｔｅｌｌｉｇｅｎｔ  Ｐｌａｔｆｏｒｍ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｔｅｒｆａｃｅ」を示す）は、情報システムの外部処理用の標準化インターフェースであり、本明細書では、サーバを、外部ユーザによって、外部ユーザのパソコンを介して処理することができる。
【００２８】
好ましくは、前記ＩＰＭＩ通信プロトコルは、イーサネット（登録商標）バス上で実行される。イーサネット（登録商標）バスは、外部ユーザのＰＣ型コンピュータとサーバのサービスプロセッサとの間でコマンドを、ＩＰＭＩプロトコルで送信する有効なゲートウェイである。
【００２９】
好ましくは、前記内部レジスタは、サーバの１つ以上のコンポーネント、前記コンポーネントに囲まれ得る１つ以上のＣＰＵ及び／または１つ以上のＡＳＩＣ及び／または１つ以上のＦＰＧＡに属する。その内部レジスタが外部ユーザによって処理されるであろう広範囲にわたるコンポーネントは、本発明によって提供される内部レジスタへのアクセス方法をなおいっそう便利にする。なぜなら、このアクセス方法は、簡易化され、より流動的にされているからである。
【発明の効果】
【００３０】
本発明は、外部ユーザによるサーバの内部レジスタへのアクセスを容易にすることができる。
【００３１】
本発明のその他の特徴及び利点は、添付の図面を参照して例示として与えられる、以下の本発明の好ましい実施形態の記載を読むことで明らかになろう。
【図面の簡単な説明】
【００３２】
【図１】図１は本発明の一実施形態に係るサーバの内部レジスタにアクセスする方法を実行する際に、サーバの内部レジスタに関連する情報のより高層への送出を実行するソフトウェアアーキテクチャの例を概略的に示す図である。
【図２】図２は本発明の一実施形態に係る、図１のソフトウェアアーキテクチャに対応する、Ｐｙｔｈｏｎ言語についての対象物分類の木構造の例を概略的に示す図である。
【図３】図３は本発明の一実施形態に係る、図１のソフトウェアアーキテクチャに対応する、Ｐｙｔｈｏｎ言語についてのコンポーネントの例示的な図を概略的に示す図である。
【図４】図４は本発明の一実施形態に係る、図１のソフトウェアアーキテクチャに対応する、外部ユーザコマンドラインに対する応答の例を概略的に示す図である。
【発明を実施するための形態】
【００３３】
本発明は、第１に、外部ユーザがサービスプロセッサによって直接的に理解可能な通信プロトコルの具体的な知識を必要とせず、第２に、外部ユーザが上記内部レジスタの構造及びそれらのサーバにおける実施についての具体的な知識を必要としないという目的を、外部ユーザからのアクセスコマンドを、１つ以上のアクセスプロトコルを用いて内部レジスタにアクセスするサービスプロセッサが直接的に理解可能な通信プロトコルを用いてサービスプロセッサに送信することと、外部ユーザによって発行されたコマンドラインを、通信プロトコルでのアクセスコマンドに、少なくとも内部レジスタの対応するアドレスと外部ユーザから供給される内部レジスタの名前とを関連付ける１つ以上のサービスモジュールを用いて自動変換することとを含んで実現するものである。
【実施例】
【００３４】
図１は、本発明の一実施形態に係るサーバの内部レジスタにアクセスする方法を実行する際に、サーバの内部レジスタに関連する情報のより高層への送出を実行するソフトウェアアーキテクチャの例を概略的に示す。
【００３５】
コンピュータシステムは、サーバ自体のコンポーネントに対応するより低い層から外部ユーザとのインターフェースに対応する最も高い層までのいくつかの重ねられた層を備える。層は重ねられているため、最も低いところから高いところまで順に、アクセスされるコンポーネント用の層７、アクセス方法用の層６、イーサネット（登録商標）バス用の層５、ＩＰＭＩツールボックス用の層４、サービスモジュール用の層３、プレゼンテーション層である層２、アプリケーション層である層１を有する。
【００３６】
アクセスされるコンポーネント層７は、それ自体が１つ以上の内部レジスタ７５を備えるいくつかの種類のコンポーネント７４を含む。これらの内部レジスタ７５が、外部ユーザがアクセスして処理及び可能であれば改変したいものである。アクセスされるコンポーネント層７は、例えば、ＣＰＵ（「中央処理コンポーネント」）型のコンポーネント７１、ＡＳＩＣ（「特定用途向け集積回路」）型コンポーネント７２、ＦＰＧＡ（「フィールドプログラマブルゲートアレイ」）型コンポーネント７３を含む。
【００３７】
層６は、アクセス方法に対応する。これは、アクセスプロトコル層６１〜６３と、アクセスプロトコル層６１〜６３の上に位置する、アクセス同時実行を処理する層６０とを含む。コンポーネント７１〜７３のそれぞれは、対応するアクセスプロトコル６１〜６３の手段によってアクセスされる。ＣＰＵ型のコンポーネント７１は、標準化された「ＰＥＣＩアクセス」（「プラットフォーム環境の制御インターフェース（Ｐｌａｔｆｏｒｍ  Ｅｎｖｉｒｏｎｍｅｎｔ  Ｃｏｎｔｒｏｌ  Ｉｎｔｅｒｆａｃｅ）」）プロトコル６１を介してアクセスされる。ＡＳＩＣ型コンポーネント７２は、「Ｉ２Ｃアクセス」（「Ｉｎｔｅｒ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ」）アクセスプロトコル６２を介してアクセスされる。ＦＰＧＡ型コンポーネント７３は、「ＸＢＵＳアクセス」（「ＸＢＵＳ」は「ＭＢＵＳ」の代わりとなる）アクセスプロトコル６３を介してアクセスされる。アクセスプロトコル６１〜６３は、それぞれアクセスコンポーネント７１〜７３に適合される。
【００３８】
アクセス同時実行処理用の層６０は、同一コンポーネントにアクセスするいくつかの同時要求がある場合に衝突リスクを処理し、それを回避する。同時実行アクセス処理層６０は、外部ユーザからのアクセス要求よりも高い優先順位を有するコンポーネントの内部レジスタのコピーを更新するために、アクセス要求の階層、監視アクセスのための要求を確立させる。アクセス方法用の層６は、サービスプロセッサ８２によって完全に処理される。
【００３９】
このようにして、これらのアクセスは、サービスプロセッサ８２上で実行される監視ソフトウェアに対して結果として干渉しない。これを得るべく、サービスプロセッサソフトウェア８２は、サーバ８３の計算コンポーネント７１〜７３への同時実行のアクセス要求を処理する。これらの同時実行アクセスは、サービスプロセッサからの内部レジスタアクセス要求と外部ユーザからの外部アクセス要求との間、または同一計算コンポーネントに外部アクセス要求を行う２人の外部ユーザ間で起こり得る。
【００４０】
アクセス同時実行処理を扱う層６０は、アクセス同時実行を処理するだけではなく、これらの動作がサーバ８３の動力ステータスにかかわらず行えることを確認する。実際に、サーバ８３へのアクセスは、電源が入っているかスタンバイであるかにかかわらず、動作中の機械において行うことができる。このため、これらのアクセスは、少なくともスタンバイモードにおいては永久的に動力を供給され、サーバ８３のＣＰＵ上にあるサービスプロセッサ８２（「処理コントローラ」）を介して行われる。
【００４１】
さらに、前記アクセスは、サーバ８３上で実行されるソフトウェアに対して干渉しない。これは、クライアントアプリケーションによって用いられるその他のプロセッサとは完全に独立してサービスプロセッサ８２を介して行われるこれらのアクセスのおかげである。アクセスプロトコル層６１〜６３は、さまざまな計算コンポーネント７１〜７３の内部レジスタ７４へのアクセスを外部ユーザからは見えない様態でサービスプロセッサ８２に処理させるようにすることができる。このため、サービスプロセッサ８２は、最初に各計算コンポーネント７１〜７３それぞれが必要なドライバを提供して、サービスプロセッサ８２を各計算コンポーネント７１〜７３のそれぞれ１つずつにリンクさせるプロトコルそれぞれの処理をも提供する。その後、サービスプロセッサ８２は、計算コンポーネント７１〜７３への同時アクセスを処理し、特に計算コンポーネント７１〜７３へのアクセスを許容する制御スイッチを処理する。次に、サービスプロセッサ８２は、サーバ処理において標準的である外部アプリケーションＩＰＭＩ型インターフェースを提供する。このインターフェースは、その入力で、計算コンポーネントの種類、そのアドレス、関連する内部レジスタのアドレス及びその内部レジスタ用の読出し及び書込みアクセスモードなどを含むいくつかの情報を取り込む。
【００４２】
イーサネット（登録商標）バスの層５は、第１に層１〜４を備える外部ユーザのパソコン８１の空間と、第２に外部ユーザがアクセスしたいと願い、層６及び７を備えるサーバ８３の空間との間の通信を可能にする。イーサネット（登録商標）バス上で行われる通信は、ＩＰＭＩプロトコルを用いる。
【００４３】
ＩＰＭＩツールキットの層４は、層５のイーサネット（登録商標）バス上に渡すように意図されるメッセージに、層３からのＩＰＭＩ言語でのコマンドを包含することを可能にする。ＩＰＭＩツールボックスの層４もまた、層６に由来し、層５のイーサネット（登録商標）バス上を通過したＩＰＭＩ言語反応の抽出を可能にする。
【００４４】
サービスモジュール３０用の層３は、外部ユーザからの高レベルのコマンドラインを、サービスプロセッサ８２によって直接的に理解される最も低いレベルのアクセスコマンドに変換することを可能にするタスクを行う。
【００４５】
したがって、いくつかのタスクが行われる。第１は、読出しまたは書込みのいずれについてかにもかかわらず、対象物分類及びそれらに関連するアクセス方法の定義付け。
【００４６】
次に、外部ユーザがアクセスしたい内部レジスタのリスト及び定義づけ。特に、それらのアドレス及びアドレス形式を有し、この位置に配列されるビットそれぞれの説明を有するサーバの内部レジスタのリスト、言い換えると、外部ユーザのパソコン空間８１におけるサービスモジュール３０の高層３にあるものが、第１に外部ユーザからの単純な構造を有する高レベルのコマンドラインを受けることを可能にし、第２にまだＩＰＭＩ言語でしか直接的にコマンドを含まないサービスプロセッサ８２をほんのわずかだけしか変更させない。最も高いレベルからのコマンドを受けられるようにするサービスプロセッサの構造の著しい変更は、外部ユーザのパソコン空間８１におけるサービスモジュール３０の、本発明によって提案される、外部ユーザの作業を例えばＰｙｔｈｏｎ言語といった高レベル言語での簡単なコマンドラインを単独で用いることでより、人間工学的及び簡単にすることにより大きく容易にするということの実施よりも、より複雑で高価となる。
【００４７】
この後に、外部ユーザからのアクセス要求を、層４にある「ＩＰＭＩツール」ツールボックスを用いてＩＰＭＩコマンドのコマンドライン形式に変換することが続く。
【００４８】
このため、サービスモジュール３０の層３は、サーバ８３の各再構成にて、計算コンポーネント７１〜７３の全ての内部レジスタ７４の全ての徹底的なリストを、各レジスタ７４について、レジスタの名前、そのアドレス、及びコンテンツの説明、すなわち、内部レジスタ７４の各ビット７５と共に生成し、更新する。
【００４９】
サーバ８３の開発のために用いられるデザインツールから自動的に生成されるこれらの情報の全ては、外部ユーザのために、内部レジスタ７４を処理するのに必要なデータの完全性、サーバ８３の各再構成にて更新することを可能とするその時間経過での実行可能性、これら同一内部レジスタ７４の処理に関与する全ての外部ユーザのための、彼らのニーズに沿って内部レジスタ７４の名前及びアドレスを探すためにさまざまな計算コンポーネントの仕様を与える書類を参照する必要がなくなった外部ユーザまたは外部ユーザのためのリアルタイム節約を含むこの情報の一貫性及び普遍性を確実にすることができる。好ましくは、さまざまな計算コンポーネント７１〜７３の内部レジスタ７４のリストは、外部ユーザに提供されるサービスモジュール３０に含まれる。このリストは、各内部レジスタ７４について、その内部レジスタ７４の名前、内部レジスタ７４のアドレス、及び内部レジスタ７４の各ビット７５の説明を含む。
【００５０】
プレゼンテーション層２は、内部レジスタ７４から上方向に送られた情報をフォーマットして、人間工学的及び外部ユーザにとって簡単に理解可能となるようにする層である。層２及び３は、ここで、例えば、Ｐｙｔｈｏｎ言語といった比較的高レベル言語で開発される。層２及び３並びにこれらの装飾物は、要素８０によって象徴化される。
【００５１】
アプリケーション層１は、パソコン８１の外部ユーザによって容易に使用可能な高レベル言語でのコマンドライン１１を含み、サーバ８３の内部レジスタ７４のビット７５を処理し、データを抽出し、さらに必要であれば変更する。サービスモジュール層３でのサービスモジュール３０の実施を通して、すなわちパソコン空間８１及びＩＰＭＩツールボックス４の上流にて、外部ユーザによる前記内部レジスタ７４の精密な処理が簡単なコマンドライン１１の使用を通して可能となる。有利に、これらのコマンドライン１１は、１つ以上のスクリプト１２にグループ分けすることができる。よって、スクリプト１２を実行させ始めることは、いくつかのコマンドラインを適切な時に自動的に実行させることができ、外部ユーザに対して内部レジスタ７４についてのさまざまな情報を直接表示させることができる。好ましくは、スクリプト１２に用いられる言語及びこれらのモジュール（「ライブラリ」）は、Ｐｙｔｈｏｎ言語であり、これによって対照指向性プログラミングも可能となる。この言語によって外部ユーザに「制御インターフェース」モードで動作するインターフェースを、また外部ユーザが書き込むことができて次の外部ユーザによっても再利用され得るスクリプト１２のライブラリをも容易に提供することができるようになる。
【００５２】
図２は、本発明の一実施形態に係る、図１のソフトウェアアーキテクチャに対応する、Ｐｙｔｈｏｎ言語についての対象物分類の木構造の例を概略的に示す。木の根２０から始まり、さまざまな計算コンポーネント２１のリストが開いていく。上から下で、最初の３つの計算コンポーネント２１は、ＡＳＩＣ型コンポーネントであり、続く３つのコンポーネント２１は、ＣＰＵ型計算コンポーネントであり、最後の計算コンポーネント２１は、ＦＰＧＡ型である。各コンポーネント２１、２２は、それぞれ複数のファイル２２、すなわち関連する計算コンポーネント２１の全ての内部レジスタ７４のリストを含む「ｒｅｇｌｉｓｔ」型のファイル２２が関連付けられており、「ｓｐｅｃ」型のファイル２２は、関連する計算コンポーネント２１のさまざまな内部レジスタ７４のコンテンツの説明を含む。外部ユーザからの高レベルのコマンドラインをサービスプロセッサによって直接理解されるＩＰＭＩ型のアクセスコマンドに変換するときに、これらのファイル２２がサービスモジュール３０によって用いられる。ファイル２２は、基本の入出力システム（ＢＩＯＳ「基本入出力システム」）の生成中に、基本入出力システムを構築するさらなる段階で生成される。
【００５３】
図３は、本発明の一実施形態に係る、図１のソフトウェアアーキテクチャに対応する、Ｐｙｔｈｏｎ言語についてのコンポーネントの例示的な図を概略的に示す。Ｐｙｔｈｏｎ言語３１で書かれる１つのコマンドライン３２について、計算コンポーネントのリストを含むファイル３３は、コマンドライン３２に一体化される欠落している情報を、この計算コンポーネントについて内部レジスタのコンテンツに関連するファイル３４に、そして特定の計算コンポーネントの内部レジスタの名前、アドレス及びアドレス指定形式を含むファイル３５に取り込むことができる。図３のファイル３４及び３５は、図２のファイル２２の詳細を示す。
【００５４】
図４は、本発明の一実施形態に係る、図１のソフトウェアアーキテクチャに対応する、外部ユーザのコマンドラインに対する応答の例を概略的に示す。第４０行は、上方向に送られる情報を示す。第４１行は、問題のサーバの種類を特定し、ここでは「Ｍｅｓｃａ２−ＥＶＴ２−ＢＣＳ４」である。第４２行は、関連する計算コンポーネントの種類を特定し、ここでは「ＦＰＧＡ  Ｎｏ．０」である。第４３行は、関連する処理動作の種類、ここでは「読出し」、及び関連する内部レジスタの種類、ここでは「ＣＩＸ＿Ｆｕｎｃｔｉｏｎａｌｉｔｙ＿Ｒｅｇｉｓｔｅｒ＿１」の両方を特定し、結果的に読み出されたものが前記内部レジスタ「ＣＩＸ＿Ｆｕｎｃｔｉｏｎａｌｉｔｙ＿Ｒｅｇｉｓｔｅｒ＿１」のコンテンツであることを特定する。第４４行は、最初に内部レジスタのアドレスを与え、ここでは「１２」であり、４ビットの内部レジスタと対応し、これらのビットは次に列挙される。内部レジスタの第１ビットに対応するフィールドの名前は、ここでは「ＥＭＥＲＧＥＮＣＹ＿ＰＷＲＯＦＦ」であり、その値は０である。第２の内部レジスタビットに対応するフィールドの名前は、ここでは「ＭＲＭ＿ＨＯＴ＿ＰＬＵＧ」であり、その値は０である。第３内部レジスタビットに対応するフィールド名は、ここでは「ＰＣＩＥ＿ＨＯＴ＿ＰＬＵＧ」であり、その値は１である。第４内部レジスタビットに対応するフィールドの名前は、ここでは「ＬＣＰ＿ＰＷＲＯＮ」であり、その値は１である。第１と第４ビットは、電力供給の状態に関連し、第２と第３ビットは、接続状態に関連する。オペレーティングシステム（ＯＳ）が後で取って代われるように、計算コンポーネントの内部レジスタの状態は、サーバの一次構成の説明を与える。
【００５５】
本発明は、明らかに、記載及び図示される実施例及び実施形態に限定されず、当業者がアクセス可能な数々の変更が可能である。
【産業上の利用可能性】
【００５６】
この発明に係るアクセス方法は、各種分野で用いることが可能である。
【符号の説明】
【００５７】
１１  コマンドライン
３０  サービスモジュール
６１〜６３  アクセスプロトコル
７４  内部レジスタ
８２  サービスプロセッサ
８３  サーバ
ＩＰＭＩ  通信プロトコル
【図１】
2016004587.tif 000003
【図２】
2016004587.tif 000004
【図３】
2016004587.tif 000005
【図４】
2016004587.tif 000006
【外国語明細書】
METHOD FOR ACCESSING MULTIPLE INTERNAL REGISTERS OF A SERVER
FIELD OF INVENTION
The invention relates to methods for accessing multiple internal registers of a server.
BACKGROUND OF THE INVENTION
In the prior art, it is known for an external user of a server to directly supply access commands in a communication protocol directly understandable by this service processor to the service processor that is managing access to internal registers of that server,.
Nevertheless, in order to do this, the external user must be in a position to master not only the type of internal registers but also their address or even their content or addressing format along with the communication protocol. This makes access to these internal registers somewhat complicated for an external user.
Moreover, as the average external user may not have complete control over all of this information, the risk of error is not negligible.
SUMMARY OF THE INVENTION
The aim of the present invention is to provide a method for accessing internal registers of a server which at least partially overcomes the aforementioned drawbacks.
More particularly, the invention aims to provide a method for accessing internal registers of a server that firstly does not require detailed knowledge on the part of the external user of the communication protocol directly understandable by the service processor and, secondly, does not require either a detailed knowledge by the external user of the structure of said internal registers and their implementation in the server. This in order to make access to these internal registers by the external user both more ergonomic and more safe, in other words that access to internal registers becomes easier and presents a risk of error that is eliminated or at least greatly reduced.
For this, the invention, after having highlighted the difficult nature of accessing internal registers by the external user and the particular interest that there might be in making these internal registers accessible even to an external user who is not a specialist in either the communication protocol or even the structure and implementation of said internal registers, simultaneously provides for information about the structure and implementation of said internal registers to be passed up to a higher layer or layers of the system, and at this or these higher layer(s), provides for means for translating commands in a relatively high-level language into this communication protocol.
The passing of this information to a higher layer or layers and the implementation of a translation means represents a system-modification effort that seems at first sight significant but which is, however, largely made profitable by the fluidity and ease of access to internal registers of the server the invention provides for the external user, not to mention the substantial reduction in the risk of error, particularly in terms of incorrect addressing of the internal registers.
To this end, the present invention provides a method for accessing a plurality of internal registers of a server, comprising transmitting access commands originating from an external user of the server to a service processor of said server using a communication protocol directly understandable by said service processor, access by said service processor to said internal registers using one or more access protocols to access said internal registers, automatic transformation of command lines issued by said user into access commands in said communication protocol by one or more service modules, the language of said command lines being of higher level than that of said communication protocol, said one or more service modules mapping names of said internal registers contained in said command lines to at least the corresponding addresses of said internal registers in said access commands, the method being characterized in that on the occasion of a user-commanded access by said service processor to said internal registers, a possible risk of collision with a monitoring access under direct control of said service processor to said internal registers for the purposes of updating a copy of the status of said internal registers is managed by said service processor.
Access to an internal register of the server is a read access or a write access. An internal register of a server is an internal register of a computing component of the server which is distinct from a memory, the server comprising computing components and memories. The dedicated nature of the communication protocol and the relatively hidden or buried nature of the information relating to internal registers, does not predispose to performing passage up to the highest layers of the system.
During said access by the service processor to the internal registers, commanded by the user, a possible risk of collision with a monitoring access to said internal registers, commanded directly by said service processor in order to update a copy of the status of said internal registers is managed by the service processor. Thus, the service processor, upon directly receiving both types of requests for access to internal registers, one from the external user just like one from the monitoring process, can, at its level, manage the risk of collision and consequently obviate it more readily.
To this end, the present invention also provides a user interface, for accessing multiple internal registers of a server, adapted to transmit access commands originating from a user external of the server to a service processor of the server, using a communication protocol directly understandable by said service processor for access by said service processor to said internal registers, using one or more access protocols to said internal registers, characterized in that it comprises one or more service modules adapted to automatically transform command lines issued by said user into said access commands in said communication protocol, the language of said command lines being of a higher level than that of said communication protocol, and for associating to the names of said internal registers contained in said command lines, at least the corresponding addresses of said internal registers in said access commands.
According to embodiments of the invention, provision is consequently made to provide external users with a simple access method, whether for reading or writing, to the internal registers of computing components of a server.
According to a preferred embodiment of the invention, provision is consequently made to provide a command line interface in order to be able to read and write the internal registers of computing components and also giving the ability to write scripts by providing Python modules to the external user.
According to embodiments of the invention, provision is made to carry out these accesses on a machine even if the latter is in operation.
According to embodiments of the invention, provision is made to generate a complete list of all internal registers with their name, address and description of their content, to provide a scripting language with modules that hide from the user, in other words make it transparent for him, all or part of the following elements, which include: the method of access to these registers, the problem of concurrent access to these registers because of the fact that the machine is in operation, the address of the registers and the powered status of the server.
According to preferred embodiments, the invention comprises one or more of the following features that can be used separately or in partial or full combination therebetween, in particular with one of the foregoing subject matter.
Preferably, said one or more service modules associate to the names of said internal registers contained in said command lines, also addressing formats corresponding to said internal registers, in said access commands. Thus, all relevant information to allow the service processor to access internal registers is incorporated into the access commands and will not need to be added in another additional step.
Preferably, at least one of said service modules contains a list of names of said internal registers associating to said names, the corresponding addresses of said internal registers, said list comprising preferably all said internal registers that may be accessed by said user, and at each server configuration, this list is updated. The updating of the list of internal registers upon each server configuration is particularly advantageous because it guarantees the external user access to all internal registers that may be of interest at any time, and this, even if at a given point in time, the structure or the implementation of an internal register is modified. If this were not the case, on the occasion of such a modification, access to the internal register could not take place until such point that an update operation for the modification of this internal register had not been performed elsewhere.
Preferably, said list also associates to said names and to said addresses, a description of all the bits of said internal registers. As a consequence, not only is access to the internal registers guaranteed to the external user, but also fine-grained operations, such as changing or analyzing a particular bit, are rendered possible.
Preferably, said risk of collision is avoided by putting on hold said access commanded by said user during all stages of the progression of a said monitoring access which will not be interrupted. Indeed, a slight delay in access commanded by the external user does not have serious consequences, while a poorly controlled disturbance occurring in the middle of the monitoring process can significantly degrade system operation.
Preferably said progression of a said monitoring access includes at least the sequence of a reconfiguration of a multiplexer located between the service processor and said internal registers and a step of reading at least one of the internal registers. The interruption of the monitoring process that could occur just between the reconfiguration of the multiplexer and the reading would significantly disrupt the operation of the system since it would be another access request, just the one originating from the user, which would inherit the reconfiguration planned for the access request by the monitoring process.
Preferably, said command lines can be grouped into one or more scripts. Thus, the management of said internal registers by the external user is made more fluid for the external user. A command line interface is a man-machine interface in which communication between the user and the computer is performed in text mode, the user typing text commands and reading text responses. A script is a program that allows the execution of tasks without requiring compilation, merely using interpretation.
Preferably, the command lines only require the user to supply the name of the internal register to be accessed, excluding its address, its address format, and its access mode. Thus, the management of said internal registers by the external user is made even simpler for the external user.
Preferably, in response to one of the command lines from the user, the bit values ??of said internal registers are displayed together with the names of the field corresponding to these bits. Thus, the external user can verify, bit-by-bit for each internal register, that its content matches the information he expects to find. This added security will allow the external user to immediately notice a change in the structure of an internal register which had not previously been brought to his attention or which might have escaped his attention, or to perform fine-grained configuration of an internal register if necessary.
Preferably, the language of said command lines is the Python language. This language is particularly simple and fluid for the external user, for the management of the internal registers of the server. Python is a known high-level programming language, with limited syntax for command lines, and particularly effective in a scripting context.
Preferably, said communication protocol is the IPMI protocol. This communication protocol is particularly effective in performing intended operations on the internal registers of the server. IPMI (for "Intelligent Platform Management Interface") is a standardized interface for external management of information systems, as here where a server can be managed by an external user through the external user’s personal computer.
Preferably, said IPMI communication protocol runs on an Ethernet bus. The Ethernet bus is an effective gateway to transmit commands in IPMI protocol between the PC type computer of the external user and the service processor of the server.
Preferably, said internal registers belong to one or more components of the server, one or more CPUs and/or one or more ASICs and/or one or more FPGAs being able to be among said components. The wide variety of components whose internal registers are likely to be managed by the external user makes the method for accessing internal registers provided by the invention all the more useful, for this access method is simplified and made more fluid.
Other characteristics and advantages of the invention will appear on reading the following description of a preferred embodiment of the invention, given by way of example and with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 schematically shows an example of software architecture implementing passage up to higher layers of information relating to internal registers of a server in the course of performing a method for accessing internal registers of this server according to one embodiment of the invention.
FIG. 2 schematically shows an example of the tree structure of object classes for the Python language corresponding to the software architecture of FIG. 1, according to one embodiment of the invention.
FIG. 3 schematically shows an exemplary diagram of the components for the Python language corresponding to the software architecture of FIG. 1, according to one embodiment of the invention.
FIG. 4 schematically shows an example of a response to an external user command line, corresponding to the software architecture of FIG. 1, according to one embodiment of the invention.
DETAILED DESCRIPTION OF EMBODIMENTS
FIG. 1 schematically shows an example of a software architecture implementing passage up to higher layers of information relating to internal registers of a server in the course of performing a method for accessing internal registers of this server according to one embodiment of the invention.
The computer system comprises several stacked layers running from the lower layer corresponding to the components of the server itself to the highest layer corresponding to the interface with the external user. The layers are stacked so we have, running successively from the lowest to the highest: layer 7 for the accessed components, layer 6 for the access method, layer 5 for the Ethernet bus, layer 4 for the IPMI toolbox, layer 3 for the service modules, layer 2 which is the presentation layer, layer 1 which is the application layer.
Accessed component layer 7 includes several types of components 74 themselves comprising one or more internal registers 75. It is to these internal registers 75 which the external user wants to gain access in order to manage and possibly modify them. Accessed component layer 7 for instance includes a component 71 of the CPU ("Central Processing Component") type, an ASIC ("Application Specific Integrated Circuit") type component 72, a FPGA ("Field Programmable Gate Array") type component 73.
Layer 6 corresponds to the access method: this includes access protocols layer 61-63 and a layer 60 for managing access concurrency which is located above the access protocols layer 61 to 63. Each of the components 71-73 is accessed by means of a corresponding access protocol 61 to 63. The component 71 of the CPU type is accessed through the standardized "PECI access" ("Platform Environment Control Interface") protocol 61. The ASIC-type component 72 is accessed through the "I2C access" ("Inter Integrated Circuit") access protocol 62. The FPGA-type component 73 is accessed through the "XBUS access" ("XBUS" being an alternative to "MBUS") access protocol 63. The access protocols 61-63 are respectively adapted to access components 71-73.
Layer 60 for access concurrency management manages and avoids the risk of collision in the case where there are several concurrent requests for access to the same component. The concurrent access management layer 60 establishes a hierarchy of access requests, a request for monitoring access, for updating the copy of the component's internal registers having a higher priority than an access request originating from an external user. Layer 6 for the access method is entirely managed by service processor 82.
In this way, these accesses are consequently not intrusive with respect to the monitoring software running on service processor 82. To achieve this, service processor software 82 manages concurrent access requests to the computing components 71-73 of server 83. These concurrent accesses can occur either between internal register access requests originating from the service processor and external access requests originating from the user, or between two users who are making external access requests to the same computing component.
Layer 60 handling access concurrency management not only manages access concurrency but also checks that these operations can be carried out regardless of the powered status of server 83. Indeed, access to server 83 will be made possible on a machine in operation, whether it be turned on or on standby. For this, these accesses are made through service processor 82 ("the Management Controller") which will be permanently powered up at least in standby mode, and which is on the CPU of server 83.
Furthermore, said accesses will not be intrusive with respect to software running on server 83. This is thanks to these accesses being made through service processor 82 in total independence with respect to other processors used by client applications.
Access protocols layer 61-63 allows service processor 82 to manage access to internal registers 74 of the various computing components 71-73 in a manner transparent to the external user. For this, service processor 82 will first provide the necessary drivers for each of the computing components 71-73 as well as the management of each of those protocols linking service processor 82 to each one of the computing components 71-73. Then, service processor 82 will manage concurrent access to the computing components 71 to 73, and will manage in particular the control switches allowing access to computing components 71 to 73. Next, service processor 82 will offer an external application IPMI type interface which is standard in server management. This interface takes at its input several items of information including: the type of computing component, its address, the address of the internal register concerned and the read and write access mode for this internal register.
Layer 5 of the Ethernet bus enables communication between, firstly the space of the external user’s personal computer 81 which comprises layers 1 to 4 and, secondly, the space of server 83 to which the external user wishes to gain access and which comprises the layers 6 and 7. The communication running over the Ethernet bus uses the IPMI protocol.
Layer 4 of the IPMI toolkit makes it possible to encapsulate, in messages intended to pass on the Ethernet bus of layer 5, commands in IPMI language originating from layer 3. Layer 4 of the IPMI toolbox also allows extraction of IPMI language responses originating from layer 6 and that have passed on the Ethernet bus of layer 5.
Layer 3 for service modules 30 performs the tasks that will enable high-level command lines from the external user to be transformed into access commands of the lowest level which will be directly understood by service processor 82.
Several tasks are thereby performed. Firstly, the definition of object classes and access methods associated with them, whether this be for reading or writing.
Next, the list and the definition of the internal registers which the external user wants to access. It is in particular this list of the internal registers of the server with their address and address format, and with the description of each of their bits arranged in this place, in other words which is at this high layer 3 of service modules 30 in the personal computer space 81 of the external user, which firstly makes it possible to accept high-level command lines that are simple in structure from the external user and secondly to modify only slightly service processor 82 which still only contains directly commands in IPMI language. Significant modification of the structure of the service processor allowing it to accept commands from the highest level would be more complex and more costly than that of the implementation proposed by the invention, of the service modules 30 in the personal computer space 81 of the external user, which greatly facilitates the work of the external user by making it more ergonomic and easier through the sole use of simple command lines in a high-level language, e.g. the Python language.
Following this, we have transformation of the access request originating from the external user into IPMI commands command line format using the "IPMI-tool" toolbox available at Layer 4.
For this, layer 3 of service modules 30 will generate and update at each reconfiguration of server 83, an exhaustive list of all the internal registers 74 of all computing components 71 to 73, with, for each register 74, the name of the register, its address, and a description of its content, that is to say, of each of the bits 75 of the internal register 74.
All of this information, which is automatically generated from the design tools used for the development of server 83, will make it possible to ensure, for the external user, both completeness of the data he needs to manage the internal registers 74, their viability over time, which allows them to update at each reconfiguration of server 83, the consistency and universality of this information for all external users involved in the management of these same internal registers 74, which constitutes a real time saver for the external user or users who no longer need to refer to documents giving the specifications of the various computing components in order to find the name and address of one or the other of the internal registers 74 in line with their needs. Preferably, the list of the internal registers 74 of the various computing components 71-73 is included in the service modules 30 provided to the external user. This list contains, for each internal register 74, the name of this internal register 74, the address of the internal register 74, and a description of each of the  bits 75 of the internal register 74.
Presentation layer 2 is a layer that formats the information that has been passed upwards from the internal registers 74, in order to make it ergonomic and easy to understand by external users. The layers 2 and 3 are developed here in a relatively high-level language that is for example the Python language. All the modifications made to layers 2 and 3 and their enrichment is symbolized by the element 80.
Application layer 1 includes command lines 11 in high-level language that will be able to be easily used by the external user of personal computer 81 in order to manage, extract data, and even modify, if needs be, the bits 75 of the internal registers 74 of server 83. Through the implementation of the service modules 30 at the service modules layer 3, in other words in the personal computer space 81 and upstream of the IPMI toolbox 4, precise management of said internal registers 74 is made possible for the external user through the use of simple command lines 11. Advantageously, these command lines 11 can be grouped into one or more scripts 12. Thus, starting a script 12 running can automatically execute at the appropriate time several command lines and bring up directly on the display various information on internal registers 74 for the external user. Preferably, the language used for script or scripts 12 and their modules ("libraries") is the Python language, which also allows object-oriented programming. This language makes it possible to easily provide the user with an interface operating in "control interface" mode, as well as with libraries from which the script or scripts 12 can be written by an external user and reused by the next external user.
FIG. 2 schematically shows an example of the tree structure of object classes for the Python language corresponding to the software architecture of FIG. 1, according to one embodiment of the invention. Starting from a root 20 of the tree the list of the various computing components 21 unfolds. From top to bottom, the first three computing components 21 are ASIC-type components, the following three components 21 are CPU-type computing components, while the last computing component 21 is of the FPGA type. Each component 21, 22 has associated therewith multiple files 22, namely file 22 of type "reglist" which comprises a list of all the internal registers 74 of the computing component 21 concerned, while the file  22  of type "spec" contains a description of the content of the various internal registers 74 of the computing component 21 concerned. It is these files 22 that will be used by service modules 30 when transforming high level command lines from the external user into access commands of type IPMI directly understood by the service processor. The files 22 are generated during the generation of the basic input/output system (the BIOS "Basic Input Output System"), in a further step in building the basic input/output system.
FIG. 3 schematically shows an exemplary diagram of the components for the Python language corresponding to the software architecture of FIG. 1, according to one embodiment of the invention. For one command line 32 written in the Python language 31, the file 33 containing the list of computing components can fetch the missing information to be integrated into the command line 32, into file 34 concerning the contents of the internal registers for this computing component and into the file 35 containing the name, address and addressing format of the internal registers of the particular computing component. Files 34 and 35 of FIG. 3 give details of files 22 of FIG. 2.
FIG. 4 schematically shows an example of a response to an external user command line, corresponding to the software architecture of FIG. 1, according to one embodiment of the invention. Line 40 indicates the information being passed upwards. Line 41 specifies the type of server in question, here "Mesca2-EVT2-BCS4". Line 42 specifies the type of computing component concerned, here "FPGA No. 0". Line 43 specifies both the type of management operation concerned, here "read", and the type of internal register concerned, here "CIX_Functionality_Register_1", consequently that it was the contents of said internal register "CIX_Functionality_Register_1" which was read. Line 44 gives first the address of the internal register, here "12", corresponding to an internal register of 4 bits, these bits then being enumerated. The name of the field corresponding to the first bit of the internal register is here "EMERGENCY_PWROFF" and its value is 0. The name of the field corresponding to the second internal register bit is here "MRM_HOT_PLUG" and its value is 0. The field name corresponding to the third internal register bit is here "PCIE_HOT_PLUG" and its value is 1. The name of the field corresponding to the fourth internal register bit here is "LCP_PWRON" and its value is 1. The first and fourth bits concern states of the power supply, while the second and third bits relate to connection states. The state of the internal registers of the computing components gives a description of the primary configuration of the server so that the operating system (OS "Operating System") can then take over.
Obviously, the present invention is not limited to the examples and the embodiments described and depicted but is capable of numerous variants accessible to persons skilled in the art.
CLAIMS
1. A method for accessing a plurality of internal registers (74) of a server (83), comprising:
- transmitting access commands (11) originating from an external user of the server (83) to a service processor (82) of said server (83) using a communication protocol (IPMI) directly understandable by said service processor (82),
- access by said service processor (82) to said internal registers (74) using one or more access protocols (61 to 63) to access said internal registers (74),
- automatic transformation of command lines (11) issued by said user into access commands in said communication protocol (IPMI), by one or more service modules (30), the language (Python) of said command lines (11) being of higher level than that of said communication protocol (IPMI), said one or more service modules (30) mapping names of said internal registers (74) contained in said command lines (11), to at least the corresponding addresses of said internal registers (74) in said access commands,
characterized in that on the occasion of a user-commanded access by said service processor (82) to said internal registers (74), a possible risk of collision with a monitoring access under direct control of said service processor (82) to said internal registers (74) for the purposes of updating a copy of the status of said internal registers (74), is managed by said service processor (82).
2. The access method according to Claim 1, characterized in that said one or more service modules (30) associate to names of said internal registers (74) contained in said command lines (11), also addressing formats corresponding to said internal registers (74) in said access commands.
3. The access method according to any one of the preceding claims, characterized in that at least one of said service modules (30) contains a list of names of said internal registers (74) associating to said names, corresponding addresses of said internal registers (74), said list comprising preferably all said internal registers (74) which may be accessed by said user, and in that, upon each configuration of the server (83), said list is updated.
4. The access method according to Claim 3, characterized in that said list also associates to said names and said addresses, a description of all the bits (75) of said internal registers (74).
5. The access method according to any one of the preceding claims, characterized in that said risk of collision is avoided by keeping said access controlled by the user on hold during all stages of progression of said monitoring access which will not be interrupted.
6. The access method according to Claim 5, characterized in that the progression of said monitoring access comprises at least the sequence of one of a step of reconfiguring a multiplexer located between the service processor (82) and said internal registers (74) and a step of reading at least one of said internal registers (74).
7. The access method according to any one of the preceding claims, characterized in that said command lines (11) can be grouped into one or more scripts (12).
8. The access method according to any one of the preceding claims, characterized in that the command lines (11) only require a user to supply a name of the internal register (74) to be accessed, to the exclusion of its address, its address format and its access mode.
9. The access method according to any one of the preceding claims, characterized in that, in response to one of said command lines (11) from said user, values ??of bits (75) of said internal registers (74) are displayed together with field names corresponding to these bits (75).
10. The access method according to any one of the preceding claims, characterized in that the language of said command lines (11) is Python.
11. The access method according to any one of the preceding claims, characterized in that said communication protocol is the IPMI protocol.
12. The access method according to Claim 11, characterized in that said IPMI communication protocol runs on an Ethernet bus.
13. The access method according to any one of the preceding claims, characterized in that said internal registers (74) belong to one or more components (71 to 73) of the server, one or more CPUs, and/or one or more ASICs, and/or one or more FPGAs that may be one of said components (71 to 73).
?
ABSTRACT OF THE DISCLOSURE
A method is provided for facilitating access by an external user to the internal registers of a server comprising: transmitting access commands originating from the external user to a service processor using a communication protocol directly understandable by the service processor which accesses the internal registers using one or more access protocols, automatically transforming command lines issued by the user into access commands in the communication protocol using one or more service modules which associate at least the corresponding addresses of the internal registers with the names of the internal registers supplied by the external user. On the occasion of a user-commanded access by the service processor to the internal registers, the service processor is responsible for managing a possible risk of collision with a monitoring access to the internal registers for the purposes of updating a copy of the status of the internal registers.
【図１】
2016004587.tif 000007
【図２】
2016004587.tif 000008
【図３】
2016004587.tif 000009
【図４】
2016004587.tif 000010