Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP- UX Developer Edge

SolarisとHP-UXの間のカベを取り除く「SHPK」・前編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
SolarisとHP-UXの間のカベを取り除く「SHPK」・前編
既存のSolarisベースのソースコードは、当然のことながら、そのままではHP-UX上ではコンパイルできない。なぜなら両OSの間にはライブラリのAPIやヘッダファイル、スレッドやシグナル、コンパイラオプション、makeツールなどの違いがあるからだ。とはいえ、数10万行や数100万行といった大規模アプリケーションに対してこうした違いを手直しするには膨大な工数が発生する。この問題を解消するのが「Solaris to HP-UX Porting Kit(SHPK)」である。SHPKでは、両OS間の違いを吸収する環境を提供することで、SolarisのAPIやヘッダファイル、makefileなどをそのままHP-UX上でも利用可能になる。
SolarisとHP-UXの間のカベを取り除く「SHPK」・前編
SolarisとHP-UXの間にあるカベ
SHPKとは
2006年2月
テクニカルライター 吉川和巳

SolarisとHP-UXの間にあるカベ

既存のSolarisベースのソースコードは、当然のことながら、そのままではHP-UX上ではコンパイルすることはできない。なぜなら、SolarisとHP-UXの間にはおもに以下のような点で違いがあるからだ。

  • ライブラリのAPI
  • ヘッダファイルの構成、定義
  • スレッドやシグナルの機能、動作
  • コンパイラの動作、オプション
  • makeツールの機能
  そこで、SolarisアプリケーションをHP-UX上に移行するには、これらの違いをひとつひとつ修正していくポーティング作業が不可欠となる。とはいえ、数10万行や数100万行といった大規模アプリケーションでは膨大な工数が発生するうえ、そのコストを事前に見積もることさえ難しい。

この問題を解消すべくHPが昨年9月にリリースしたのが、「Solaris to HP-UX Porting Kit(SHPK) 」である。SHPKは、Solaris対応のC/C++ソースコードのHP-UXへの移行を支援するツールである。その最大の特徴は、上述したような両OS間の違いを吸収する環境を提供すること。つまりSHPKを使えば、SolarisのAPIやヘッダファイル、makefileなどをそのままHP-UX上でも利用可能になる。これにより、ポーティング作業に必要な労力を大幅に軽減できる仕組みだ。
 
図1:SHPKによるSolarisからHP-UXへの移行
図1:SHPKによるSolarisからHP-UXへの移行
 
今回は、このSHPKを活用することでSolarisからHP-UXへのポーティング作業がどの程度まで簡素化されるか、その実力を検証したい。


SolarisからHP-UXへの移行手順

まずは、SolarisからHP-UXへのアプリケーション移行に必要な個々の手順をおさえておこう。一般に、異なるOS間でのアプリケーション移行には、以下の3段階の手順が必要となる。

  • アセスメント
  • ポーティング
  • テスト
 
図2:アプリケーション移行の流れ
図2:アプリケーション移行の流れ

アセスメント

  アセスメントでは、ポーティング作業に先立ってさまざまな観点から事前調査を実施する。例えば、以下のようなポイントについて調べておく。

  • ポーティング作業を支援するにはどのようなツールやドキュメントが利用可能か
  • 互換性の無いAPIや型を使用しているか
  • 互換性の無いシステムファイルを利用しているか
  • データファイル等で互換性の無いものがあるか(エンディアンなど)
  • ISVライブラリまたはプラットフォーム依存のライブラリを使用していれば、それが移行先においても利用可能か
  • 現在利用できないような古い開発環境に依存しているか
  • 古い仕様のコンパイラを使っているか(C言語のK&R、C++のARMなど)
  • 移行時に32bitのソースコードを64bit化する必要があるか
  • マシンコードやpragmaなどプラットフォーム依存のものが含まれているか
  • 浮動小数点演算処理の精度や処理方法の違いが問題にならないか
  • 移行元でテストが定義されているか、またテスト環境構築に工数が必要か
  これらのポイントについて調査したのち、実際にいくつかのモジュールを移行してみる「サンプルポーティング」を実施する。これにより、コンパイル時にツールやライブラリが正しく利用できることや、データの移行に問題がないことを確認できる。最後に、サンプルポーティングに必要とした工数をもとに、ソースコード全体を移行するのに必要な工数を見積もる。

ポーティング

  ポーティングでは、アセスメントの結果に基づいて実際に移行作業を進めていく。具体的には以下のような作業を実施する。

  • ビルド環境の変更(makefileやコンパイラオプション、ツールのオプションなど)
  • ソースコードの変更(APIや型の違い)
  • データファイルの移行

テスト

 

テスト作業では、移行元の環境で行われていたものと同様のテストを実施する。とりわけアプリケーション移行では、以下の点が重要なポイントとなる。

機能テスト
ポーティングして生成した各実行ファイルが正しく動作することを確認するためにそれぞれについて単体テストを行う。さらに、データベースとの接続やネットワークを介した他のアプリケーションとの連携などを検証する接続テストも行う。ポーティング後は、タイミングの問題やメモリ使用量といったOSの動作の違いが、ポーティングしたソフトウェアの動作に反映し、正しく動作しないことがある。この場合、問題の絞り込みやデバッグなどを行い、必要に応じてソースコード変更する必要がある。

負荷テスト・長時間運用テスト
これらのテストにより、メモリ等のリソース使用量やパフォーマンスが適切なものかどうかを調べる。メモリリークなどもチェック項目となる。また、カーネルパラメータなどOSの設定を変更する必要がある場合もある。

パフォーマンステスト
ポーティングしたソフトウェアが適切な実行速度で動作するかどうかをテストする。対象ソフトウェアをSolaris上で動作させた場合の実行速度を比較対象とし、移行先のハードウェアスペックを考慮して適切な実行速度を求める。適切なパフォーマンスが得られない場合は、プロファイリングやトレースなどをとってボトルネックを調べ、問題点を改善する。


  さて、アプリケーション移行に必要なこれらの手順の中でも、とりわけSHPKが威力を発揮するのはポーティング作業である。ビルド環境やソースコードの変更に際して、従来のような地道な手直しの必要性を大幅に減らしている。つづいては、SHPKの基本的な仕組みや利用方法について紹介しよう。

トップへ   次のページへ

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項