第 18 部
オペレーティングシステム

699

第 1章はじめにWIDE OS ワーキンググループにとって 1993 年度はある意味で非常に重要な年となった。
WIDE プロジェクトは 1990 年からカリフォルニア大学バークレー校の Computer Systems
Research Group(CSRG) と共同研究を行っている。CSRG による NET/2(Network Release2) のリリースは、USL との訴訟問題が発生し配布が一時中断されていたものの 1994 年の 2 月に解決、最終的に 4.4BSD-Lite として登場する。これによって我々は良質なオペ
レーティングシステムのソースコード を再び自由に入手することが可能になった。本論
文はまず最初に 4.4BSD を中心に最近の UNIX 系オペレーティングシステムの標準化の動向などについてまとめたものを報告する。
一方で我々を取り巻く計算機環境は大きく変化し従来のワークステーションを中心とした固定的な運用形態に加えて、ノートやサブノートと呼ばれる小型で携帯可能な計算機が登場している。これらの多くは UNIX をサポートできるだけの性能をもっているにもかかわらず、オペレーティングシステム側で十分に生かせるだけの機能を用意していない。携帯型の計算機で UNIX のようなオペレーティングシステムを運用することを考えた場合、従来あまり考える必要のなかった、

 移動するノードを考慮したネットワーク機能や分散ファイルシステム
 パラレルポートや IC カードに接続するといった付加的なデバイスド ライバ
 レジューム機能を用いた運用や、バッテリーによる運用を考慮した細かなパワーマ
ネジメント機能などが必要だと考えられる。前者は VIP ワーキンググループや分散ファイルシステムのワーキンググループの方で報告があるだろう。本論文ではパワーマネジメントシステム
について報告する。
次にオペレーティングシステムの国際化について考えてみると、現在多くのベンダー
製のオペレーティングシステムでは国際標準化案にしたがった国際化機能が用意されている。しかし実際にはそれぞれのベンダー独自の思惑による実装がなされた為か利用するユーザ側の立場が考慮されているとはいえない。またソースコードが入手困難である
ことも WIDE プロジェクトにとって利用しにくい原因となっている。本論文では我々が開発した ISO C MSE(Multibyte Support Extension) 準拠マルチバイト文字処理関数ライブラリの実装レポートを報告する。

701

702

1993 年度 WIDE 報告書

最後に新しいオペレーティングシステム実装の試みとして、Cubix OS を紹介する。これは 64 ビットプロセッサで提供し うる 64 ビットの広大な仮想アドレス空間を積極的に利用した SASOS (Single Address Space OS) のコンセプトから生まれたものである。

第 2章
BSD Unix 系オペレーティングシステムの動向
1993 年 6 月、最後の BSD Unix であるとかねてから噂されていた 4.4BSD がリリースされた。BSD Unix を開発してきた University of California Berkeley (UCB) の CSRG
(Computer Systems Research Group) は、この 4.4BSD をもって BSD Unix の最後のリリースとし 、CSRG 自身も解散することを宣言している。ここでは 4.4BSD を中心とした最近の BSD Unix の動向についてレポートする。

2.1

4.4BSD 以前

BSD (Berkely Software Distribution) Unix という名前で本家 AT&T Bell 研究所の Unixから離れ独自の発展を遂げてきた UCB CSRG による Unix は 、1986 年に 4.2BSD で
ネットワーク機能がサポートされたのを機に、研究者の枠を超えて広く利用されるようになった。さらに、その改良版である 4.3BSD (1988 年) はワークステーション用の OSとして多くの機種によって採用され、現在のワークステーションの普及の大きな原動力となった [240]。
4.3BSD 以降もマイナーリリースは続けられ、1988 年には VAX に加えて CCI Powerという新しいアーキテクチャをサポートした 4.3BSD-Tahoe が配布され、その年の末には BSD Networking Software という名前で 4.3BSD-Tahoe の中のフリー部分が配布されている。
1990 年の 4.3BSD-Reno 版は、マイナーリリースながら OSI ネットワーク、NFS (Network File System) [241] [242] 、MFS (Memory File System) [243] などの多くの新機能をサポートした。主な特徴を次に挙げる。

 DEC VAX 8600, 8650, 8200, 8250, MicroVAX II, III サポート HP, i386 サポート
 ISO/OSI ネットワークプロトコル
 VFS 仮想ファイルシステム
 NFS ネットワークファイルシステム
 MFS メモリファイルシステム
703

1993 年度 WIDE 報告書

704

 FFFS (Fat Fast File System) Kerberos 認証機構
 カーネル内汎用メモリアロケータ
 TCP/IP の拡張 (ヘッダ予測、CSLIP、階層的経路制御など ) 新 QUOTA システム
 IEEE 1003.1
翌 1991 年にリリースされた BSD Networking Software, Release 2 は、やはりライセン
スフリー部分のみからなるものだが、それまでの課題であった仮想記憶システムを根本的に入れ替えた大幅なバージョンアップで、内容的には 4.4BSD のプレリリースと呼ぶべきものであった [244]。ただし USL のライセンスに抵触しない部分のみのリリースであったため、カーネルの中の一部のモジュールが欠如していたり、存在しないコマンドもあった。その後このリリースは NET/2, net2 などと呼ばれる。
NET/2 には、もう 1 つ大きな特徴があった。Intel 386/486 アーキテクチャをサポートしたフリーのコードであったという点である。実際にそのコードを実装したのは CSRG ではなく William Jolitz であった。Jolitz は、4.3BSD-Reno がリリースされる前から 386BSDという名前で 4.2BSD の IBM-PC への実装を行っていた。彼はそれを CSRG に寄付し 、世の中の多くの PC ユーザが BSD Unix を手に入れられることを望んでいた。NET/2 には彼の寄付したコードが含まれていたが、カーネルの非常に重要な部分が欠如したものであったため、それを元にしてすぐに PC 上で BSD Unix が利用できるユーザは相変わらず少数だった。
NET/2 は未完成な OS だったが、再配布が自由であることから先の BSDI 以外にもそれを元にして OS を開発、配布する動きが活発になった。William Jolitz は独自に 386BSDのサポートを開始し 、BSDI 社の BSD/386 、 Mach の BSD サーバである BNR2SS などがこれに加わる。現在では 386BSD はさらに NetBSD, FreeBSD などの支流を生み出している。
BSD Unix は、AT&T ベル研究所によって開発されたコードを元にして作られているため、利用に際しては元となるコード の使用権が必要である。現在その権利を持つ USL(Unix System Laboratories) は、 NET/2 を USL のライセンスに無関係に配布することは違法であるという見解を持ち、BSDI とカリフォルニア大学に対して訴訟を起こした。
しかし USL が BSDI 社に求めていた配布差し止めの要求は裁判所によって却下され 、
BSD/386 は正式に出荷されることとなった。Novell による USL の買収、Unix 商標権のX/Open への売却など 、USL をめぐる情勢は非常に大きく変化しており、訴訟の行方にも影響を与えると思われていたが、1994 年 2 月になってようやく和解するに至った。

2.2

4.4BSD

1992 年 7 月付で、4.4BSD-Encumbered という名前で 4.4BSD のアルファリリースがアナウンスされた (日本に対しては 1993 年に 2 月頃に配布が始まった) 。そのアナウン

第 18 部

オペレーティングシステム

705

スの直前、4.4BSD のリリースを最後に CSRG は解散し 、今後 BSD Unix の開発は行わないという発表があった。理由としては、世界的な不景気の影響を受け開発資金の調達が困難になってきたこと、BSD Unix に対する社会的必要性が薄れてきたこと、主力メンバーである Mike Karels を失ったこと (これも原因は資金難である) 、などが挙げられている。
1993 年 6 月 1 日付で、CSRG から 4.4BSD 最終リリースの案内があった。冒頭には次のような言葉で、それが CSRG が配布する最後の Unix であることが宣言されている。

This distribution is the nal release that will be done by the Computer
Systems Research Group (CSRG).
4.4BSD が最終的にサポートしたハード ウェアは次の通りである。
hp300
pmax
sparc
luna68k
news3400

HP 9000/300 シリーズ
DECstation 3100/5000
SparcStation 1, 2
Omron Luna
Sony NEWSHP と Luna は Motorola 68030/40 、DEC と Sony は MIPS R2000/R3000 、Sun は
SPARC をそれぞれ CPU としている。DEC と Sony は同じ MIPS の CPU を使用しているが、バイト順序が異なる。
この他、386BSD や BSD/386 のベースとなっている Intel の 386/486 のコードも入る
が、NET/2 のコードがそのまま入っているため、カーネルの他の部分の変更に追随していないのでそのままでは動作しない。VAX と Tahoe のコードも含まれているが、これらは新しい仮想記憶システムに対応していないため、まったく動作しない。Kirk McKusickによれば 、VAX の仮想記憶を新しいものに対応させるのは 1ヶ月程度の作業だろうということだった。
CSRG が主な開発環境として使用しているのは、HP-9000 の 300 シリーズである。したがって、このコードが最も安定している。
OMRON Luna は同じ CPU を使用する HP と構成がよく似ていて、共有するコードも多い。HP は現在の BSD のリファレンスマシンであるから、Luna のコードの質もかな
り高いと言ってよいだろう。リリース直前に 68040 ベースの Luna II もサポートされた。
Sony NEWS のサポートは WIDE プロジェクトの一環として Sony の協力を得て行ったものである。こちらは pmax (DECstation) との共有部分が多く、マシン異存のファイルのうちで pmax へのシンボリックリンクになっているものも少なくない。現在 NWS-3200,
NWS-3400 等シングルプロセッサの RISC マシンで動作し 、CISC マシンや NWS-3800
等の I/O プロセッサ付きの機種はサポートしていない。
4.4BSD-alpha と 4.4BSD は、機能的にはほとんど違いはない。主な特徴を次に挙げる。

1993 年度 WIDE 報告書

706

NFS (Lease) NFS (Network File System) は、カナダの Guelph 大学の Rick Macklem

が仕様を元に実装したもので、Sun の NFS と相互に接続可能である。NET/2 にない機能として、 Lease と呼ばれるキャッシュ管理のメカニズムを備えている [245][246] 。

LFS (Log-Structured File System) UCB の Sprite プロジェクトの成果で、ディスク上に連続してデータを書き込むことでディスクアクセスとヘッド のシークをできるだけ減らし 、書き込みのスループットを向上させたファイルシステムである。また、クラッシュ時の回復に要する時間も短縮されている。
スタッカブルファイルシステム UCLA の Ficus プロジェクトの成果である。ファイルシ
ステムを階層的に実現することにより、それぞれのファイルシステムの独立性を高め、新たなファイルシステムの開発を容易にし 、拡張性を向上する。 [247][248]

64 ビットファイルサイズ 従来の Unix では、ファイルのサイズは 32 ビットで表されていたため、2 ギガ以上のファイルを操作することはできなかった。昨今のハードディ
スクの大容量化により、この制限が現実の問題となってきたため、4.4BSD ではファイルサイズが 64 ビットに拡張された。

共通デバイスド ライバ 他の PC Unix で、generic scsi などと呼ばれる共通の SCSI ド ラ
イバの原型。

IEEE 1003 (POSIX) IEEE 1003 の POSIX のシステムインタフェースと、ライブラ
リ、コマンド の仕様がかなりのレベルでサポートされている。
ファイルサイズが 64 ビットになったことは、思ったよりシステムに対して与える影響が大きかった。リリースが予定よりも遅れた大きな原因になっている。NET/2 までのカーネルでも 64 ビット整数はサポートされていたが、32 ビット整数の配列で代用することができた。しかし 、4.4BSD では完全に 64 ビット対応のコンパイラでなければ 、カーネルをコンパイルすることすらできなくなっている。現在のところ 4.4BSD を作ることができるのは、おそらく gcc だけだろう。gcc 2.0 以降では、64 ビットのデータ構造が 64
ビットの境界に合わされるようになった。これによって、カーネル内のいくつかの構造の再構成が強要された。
スタッカブルファイルシステムが採用されて、何種類ものファイルシステムが採用されている。/usr/src/sys/fs の下には次のようなディレクトリが存在する。

deadfs umount されたファイルが属する
fdesc プロセスのファイルディスクリプタをアクセスする
fofs FIFO を実現する
kernfs カーネルに関する情報
lofs ループバックファイルシステム
nullfs Stackable Filesystem のスケルトン

第 18 部

オペレーティングシステム

707

portal Portal Filesystemspecfs スペシャルファイル
umapfs uid のマッピングを行う Stackable Filesystem のサンプル
また、 4.4BSD では新しく LFS (Log-Structured File System) というファイルシステ
ムが採用された。LFS は、UCB Sprite プロジェクトの成果であり、Mendel Rosenblum,
John K. Ousterhout 等によって実装された。目的は従来のファイルシステムが持つ次のような問題点を解決することである。

 ディスクのスループットは向上してもアクセス速度は変わらない read の効率はキャッシュにより解決されるので write が問題となる
 FFS では小さなファイルに書き込みを行う時には、ディスクのバンド 幅の 5% 以下
しか利用されなていない

LFS は 、以上のような問題点を解決するために、ディスクアクセスのためのヘッド のシークを極力排除するという方針をとっている。そのため、ディスクに書き出すべきデー
タは連続したブロックに更新情報として書き込まれていく。これが Log-Structured と呼ばれる所以である。Unix では、小さいファイルの作成と消去を繰り返す処理が非常に多い。この処理は inode データの更新を伴うため、物理的に離れた場所にあるデータを更新しなければならず、ディスクヘッドのオーバーヘッドが大きなコストを持ってくる。LFS
は主に、小さなファイルの作成とデータの書き込みに焦点を当てたファイルシステムである。
また、ディスクの中で最近更新したデータが局所化されているので、システムがクラッシュした際の復旧の点からも有利である。定期的にチェックポイント情報を更新し 、クラッシュした際には、最後のチェックポイントより後に更新されたデータだけを検査すればよい。従来のファイルシステムでは、ファイルシステム全体を走査して整合性の確認をしなければならなかったの対して、検査するデータ量が大幅に少なくなっている。
最終リリースではサポートされると言われていたが、結局 4.4BSD ではサポートされなかった機能がいくつかある。これは次のようなものである。

Bstreams AT&T ベル研究所の 8th Edition Unix の Streams と、BSD の socket を統合した BStreams と呼ばれる新しいインタフェース。

ネット ワークの高速化 LBL (Lawrence Berkeley Laboratory) の Van Jaconson による、
TCP/IP のネットワークコード の大幅な改良。実装上の階層をできる限り排除する
ことと、ネットワークハード ウェアからの割り込みの回数を極力減らすというのが基本的なアプローチである。
バッファキャッシュと仮想記憶の統合 現在はファイルシステムのバッファキャッシュと仮想記憶システムでは、別々のメモリプールを管理している。この 2 つを統合して、互いのメモリを単一のインタフェースで管理するというもの。

1993 年度 WIDE 報告書

708

2.3

4.4BSD 以降

日本には 1993 年の 9 月に 4.4BSD のテープが到着した。 4.4BSD-alpha の配布手数料
は $2000 で、この時 $400 の追加料金を払ったユーザに対しては、自動的に最終リリースのテープが送られてきた。テープには 3 種類あり、HP-300, SparcStation, DECstationのバイナリの中から好きなものを選択することができる。
WIDE Project でも、リリースの到着と同時に 4.4BSD の試用が何ヶ所かで行われているが、十分実用に耐えるという印象を得ている。やはりプラットフォームとしては SparcStation が多く、4.4BSD が Sparc をサポートした影響は非常に大きい。Sparc のコードに関しては、主に開発を行った LBL の Chris Torek がサポートを続けている1 。
CSRG による BSD Unix は 4.4BSD で最後になるが、NET/2 を基にした OS が非常に活発に活動を続けている。主なものは次の 4 つである。

 386BSD
 NetBSD
 FreeBSD
 BSD/386
このうち Willam Jolitz の 386BSD は、最近動きが停滞しているようだが、NetBSD,
FreeBSD の方は活発に活動を続けているし 、BSDI の商品である BSD/386 は独自に開発を行っている。
NET/2 を基にしたフリーの OS としては、現在のところ NetBSD がもっとも進んでいる。NetBSD は、現在 HP, i386, pmax, sparc という 4.4BSD でサポートしているアー
キテクチャの他、Amiga, Macintosh, Sun3, ns32532 などでも動作する。
元々は 386BSD のパッチキットを統合する形で始まった NetBSD であるが、現在は次のような NET/2 にはない機能をサポートしている。

PCFS MS-DOS ファイルシステム
BSDI バイナリ互換 BSDI の BSD/386 とのバイナリ互換性
NIS サポート Sun の NIS サポート (現在はクライアントのみ)
loadable kernel module カーネルモジュールの動的リンク
Wine Windows のバイナリ実行環境
共有ライブラリ SunOS4.X と同様の実装方法
1 ftp.ee.lbl.gov から anonymous ftp 可能である。

第 18 部

オペレーティングシステム

709

リリースされている NetBSD は現在バージョン 0.9 が最新で、開発中のものは NetBSDcurrent と呼ばれている。これも sup で公開しているため、Internet にアクセスできれば誰でも手に入れることができる。最近ではコンパイルされたバイナリーのスナップショッ
トも定期的に登録されている。また current とは別に magnum というブランチが存在し 、より 4.4BSD を統合する方向での開発が進んでいるらしい。

2.4

新 4.4BSD-Lite

4.4BSD-alpha のころから、リリースしたコード のうちフリーにできる部分を NET/2と同様な形で 4.4BSD-Lite という名前でリリースすることを CSRG はアナウンスしていた。しかし USL との訴訟問題がありこれまで配布されていなかった。
1994 年 2 月 USL と BSDI 社、USL とカリフォルニア大学との訴訟は解決した。合意の内容は次のとおりである。

 NET/2 と現行の 4.4BSD-Lite には、USL の Copyright 含まれているファイルが存在していることに合意。

 UCB は新しい 4.4BSD-Lite を開発し、該当するファイルを新しいものに置き換える。
 BSDI 社は UCB の新しい 4.4BSD-Lite をベースに BSD/386 を開発する。
 現行の BSD/386(Version 1.1) は NET/2 をベースとしているため、該当するファイ
ルをバイナリで配布する。これは BSD/386 1.1 の出荷に対する限定された措置である。

これによって、UCB は新しい 4.4BSD-Lite を配布可能となった。そして 1994 年 4 月、
新しい 4.4BSD-Lite の配布開始が NetNews 等を通じてアナウンスされた。
4.4BSD-Lite は NET/2 がそうであったように、他のフリーな BSD に由来する OS た
ちに大きな影響を与えることは間違いない。すでに次のリリースから 4.4BSD-Lite を元に開発することを表明しているものも存在している。今後の展開が楽しみである。

2.5

BSD Unix の持つ意味

BSD Unix は、多くの大学や研究機関において、長い間研究開発のプラットフォームとして利用されきた。もちろん、それは BSD がオペレーティングシステムとして優れた機能を持っていたからであるが 、それ以外に、すべてのユーザがシステム全体に関するす
べてのソースを持ち、それを自由に改変し 、情報交換を行うことが可能であったという
点は忘れてはならない。多くのユーザの研究成果は、CSRG によって正式リリースに取り入れられ、BSD 自体を改良するために貢献するという再生産の機構がうまく働いていたのである。
しかし、4.2BSD のリリース後、BSD をサポートするワークステーションが市場に現れてきた。これらは BSD がサポートする VAX-11 よりも安価で高性能であったため、ワー

710

1993 年度 WIDE 報告書

クステーションを開発の対象として使うユーザの数が圧倒的に多くなった。また、メーカが独自にサポートした機能にも優れたものがあり、もはや通常の BSD Unix には戻れなくなってしまった部分もある。たとえば Sun Microsystems の NFS (Network File System)などがそれである。しかし 、メーカのサポートする Unix にはソースコードは当然付いていない。Unix ワークステーションの普及は、Unix 文化を広めるという意味では成果を上げたが 、反面、すべてのユーザがソースコード を共有するという Unix の大きな特長を失わせてしまったのである。
WIDE Project で 4.4BSD のサポートをはじめたのには、このような背景があった。現
在 Unix 利用して教育に携わる人々の多くは、 OS やシステムコマンドのソースコードを参考にしながらプログラミングを学習したに違いない。そして、現在の教育環境に戸惑いと疑問を抱く人も少なくないだろう。4.4BSD や Mach などは教育環境に再び『ソースのある Unix 』を再現するという点で、非常に意味のある実用オペレーティングシステム
である。なかでも BSD Unix は、pdp-11 や VAX-11 上で教育・研究機関で広く使われてきた馴染みの深いものであり、現在普及しているワークステーションにも BSD Unix に由来する OS を搭載しているものは多い。多くのアーキテクチャをサポートする 4.4BSD
によって、再び開かれた Unix が手に入れられる可能性が高くなる。日常使っている環境
自体を使って学習できることによる利点は多い。
今日、ネットワークニュースから流れてくる記事を眺めていると、「パスワードを入力するときに画面に表示させないためにはどうするのですか ? 」といった質問が少なくない。
以前であれば 、このような疑問を抱いたユーザは、間違いなく passwd コマンドのソースを見つけ出し 、stty によってそれが解決することをたちどころに探り当てたはずだ。商業 Unix の普及はこのような優れた教育環境をユーザから奪い、代わりに膨大な量の関連書籍やマニュアルを生み出した。ユーザは多すぎる参考文献の中から自分の探す答え
を見つけ出さなければならない。4.4BSD-Lite のリリースは、このような状況を変えるための一石を投じるはずだ。

第 3章
携帯型計算機における UNIX の利用 (1)高性能 CPU を搭載した IBM-PC 互換機のノートブックタイプに代表されるような携帯型計算機の登場により、UNIX の運用形態も従来の固定的なものから移動しながらの運用や、バッテリーによる運用などを考慮する必要がでてきた。
携帯型計算機で UNIX を運用する場合問題となるのが、移動時における計算機の状態の保存方法と節電機能のサポートである。一般に UNIX オペレーティングシステムは、起動や停止に時間がかかる場合が多い。また移動するたびにシステムを停止していたのでは連続運用が必要なプログラムなどを動作させることができず、非常に不便である。
そのため携帯型の計算機で運用する場合、必要に応じてシステムの現在の状態を保持したまま休止したり休止以前の状態に戻す機能が必要となる。これは通称レジューム機能と呼ばれており、これによってシステムの連続運用性を確保することが可能となって
いる。

3.1

レジューム機能について多くのノートブックタイプの IBM-PC 互換機では、レジューム機能を搭載している。従来レジューム機能は、特別なハード ウェアとオペレーティングシステムによるサポートが必要なため機種依存性が高いものであった。しかし最近では、CPU 自体にレジューム
機能を用意したものが登場している。1

CPU の持つレジューム機能は、オペレーティングシステム及びアプリケーション・ソ
フトウエアからは完全に見えないようにしてシステム動作を管理する強力な機能を備えている。i486SL シリーズ (i486 Enhanced Series) は 、既存のラップトップなどに見られる電源管理機能実装で見られるような不備のない、最大限の電力削減をインテリジェン
ト型電源管理ハード ウエアを用いて実現している [249][250]。
そのような電源管理機能を持つ CPU セットを利用したノートブックに UNIX を導入する場合、オペレーティングシステムで機種依存性のある特殊なコードを用意することな
くレジューム機能を実装することが可能となるはずである。
1 例えば東芝のダイナブックシリーズに搭載されている CPU にも、このような機能が一部内蔵されている

711

1993 年度 WIDE 報告書

712

3.2

設計

レジュームは次のような場合に実行される。

 ソフトウエアでサスペンドレジスタに書き込みを行った場合
 外部装置で外部 SMI(System Management Interrupt) 入力ピンをアサート
 グローバル・スタンバイの自動電源切断オプションを使用する
 ノートブックが用意しているレジュームボタンが押された場合
 バッテリー電圧低下警告を受理した場合レジュームは、アプリケーションが実行していた情報・メモリイメージを失うことなく再始動できる最低電力を確保したうえで動作する。この場合でも基本的にメモリだけには電力が送られているため、メモリによるバッテリーの消耗は免れない。
サスペンドが実際に起動される前には、システムが DMA などの入出力操作を終了出来るようにサスペンドトリガとサスペンド 状態の開始の間にプログラムされた遅延を挿入してある。そこでサスペンドが起こった時点でメモリーのイメージをハードディスクの一部に書きこむことで、メモリによるバッテリーの消耗がない完全なレジュームをサポートすることも可能である。
レジューム機能を UNIX に導入する上で問題となったのが 、機種非依存性をどのようにして保つかということである。そのため最低条件として、CPU をレジューム機能を標準で搭載している i486SL(i486SX Enhanced Series) であることとした。
ノートブックがレジュームを行なう際、必ず、SMI が発行される。SMI は、最高優先
度のノンマスカブル割り込み (Non Maskable Interrupt | NMI) である。SMI が発行されると、CPU は次のような動作を行なう。

 System Management RAM(SMRAM) を 30000H から 3FFFFH の範囲のメインメモ

リ空間にマッピングを行なう。SMRAM は、この領域にある既存のメインメモリをオーバーレイし 、内部 IO トラップ FILO(System Management FILO) を凍結する。

 SMRAM 空間に CPU の状態を記憶する。このデータは 3FFFFH から格納され、スタック方式で下位アドレスに記録される。

 システム管理モード (System Management Mode) に移行する。
 システムアドレスの 38000H の実装トリガが 、プログラムしたシステム管理モード
ハンド ラの実行を開始する。これは、特殊 SMRAM 領域に配置される。

 CPU がシステム管理モード の実行に移り、CPU コアのセレクタが初期化される。

第 18 部

オペレーティングシステム

713

UNIX が上記状態を認知し 、自動的にレジューム処理を行なうことによって標準化が可能となる。
まず、レジュームを UNIX 側でいかに認識させるかが課題となる。例えばダ イナブッ
クでは、電源ボタンを押すことで SMI インタラプトが入る仕組みになっている。この電源ボタンはチップセット上のサスペンド・レジュームボタンピンの機能を利用している。
このピンはトグル式で、システムがサスペンド 状態でなければ 、サスペンド ・レジュー
ムボタンピンをアサートすることでレジューム機能を開始し 、システムがサスペンド 状
態であるならば 、サスペンド・レジュームピンをデアサートすることで、サスペンド 状
態からの解放が可能となっている。そのため、電源スイッチによってレジュームを動作させる場合、オペレーティングシステム側の処理を確実にサスペンド 状態へと移行することが困難であった。

3.3

実装

実装は BSD/386 上で行った、BSD/386 は BSDI 社の開発した POSIX 互換のオペレーティングシステムで University of California Berkeley (UCB) の CSRG (Computer Systems
Research Group) の開発した BSD Networking Software, Release 2(NET/2) を基に開発されたものである。BSD/386 はカーネルを含むシステムソフトウェアの殆どがソースコー
ドを含めて入手可能であり、カーネルレベルでの変更が必要になる今回のような実装を行うのに最適なシステムの一つだと考えられる。また対象マシンとしては東芝のダ イナ
ブックを用いた。
3.3.1

auto-shutdown

まず、ノートブックを shutdown したときに自動的に電源を切る機能を加えた。具体的には、shutdown コマンドを実行し 、カーネルが shutdown された時に、自動的に電源を切るコードを書き加えた (図 3.1) 。
これによって、シャットダウン時にも電源キーを触れることなく自動的に電源を切ることが可能となった。
図 3.2に見られるように autopowerdown() は機種依存となっている。これはマシンによって電源を切るアドレスが異なるためである。このため機種を自動的に判別し 、相応するアドレスを自動的に認知するようにしている。
3.3.2

resume-key

キーボード 上の特殊キー (ホットキー) の組合せによってレジューム機能を立ち上がらせる方法をカーネル上に構築した。この場合、ほぼ 、完全な形で機種非依存性を確保できる。特殊キーの組合せによって、ハードディスクの sync を行ない、 SMI を起動し 、レジュームを実行させ、電源を自動的に切る。図 3.3にそのアルゴ リズムを示す。
ここでは CTRL-ALT-DEL のキーを同時に押した時にサスペンドもしくは、システムハン
グが生じるようにカーネルの変更を行っている。すでに CTRL-ALT-DEL によるシステムハ

1993 年度 WIDE 報告書

714

:
:
doatshutdown();
if (システムが完全にシャットダウンされた。) {printf(``\nSystem is halted; %s\n\n'',``hit reset, turn power off, or press return toreboot'');#ifdef NOTEBOOK /* ノートブックの場合 */autopowerdown();#endif /* NOTEBOOK */図 3.1: ブートアルゴ リズムに追加したルーチン
ングのルーチンがカーネルに装備されているため、この部分に改良を加え、CTRL-ALT-DEL
キーを入力すると、カーネルが、システムダンプを行なうか、レジュームを行なうかの選択をするようにした。
メモリーの持つイメージをファイルとしてダンプするノートブックの場合、MSDOS のパーティションをダンプエリアとして確保しなければならない場合がある。現状のダ イ
ナブックはメモリに電力を与え、記憶確保を行なうタイプなので、その必要はない。上記
タイプのノートブックの場合、実際のメモリーイメージダンプ作業は、ノートブック内の BIOS が制御しているため、機種依存性が生じる。resumestart() 実行の際にも、機種を特定し 、機種に応じたサスペンド 機能のルーチンを起動しなければならなくなる。
3.3.3

レジュームによる時計の遅れ

レジューム機能によってシステムが停止している間、UNIX の用意している内部時計は
CPU 自体が完全に止まってしまうため進まない。これに対しハードウェアクロックはレ
ジューム時も動作しているため、システムをレジュームから復帰したときにハード ウェ
アクロックと UNIX の内部時計の間で時間のずれが生じてしまう場合がある。そのため、レジューム復帰時に UNIX の内部時計をハードウエアクロックと同期させる必要がある。
ここでは復帰時に clockadj() ルーチンを呼び出すことによって、ハードウエアクロッ
クと内部時計の同期を行なっている。(図 3.2の最後の部分) 。clockadj() の構造自体はは極めて単純なもので、ハード ウエアクロックのデータをそのまま代入し直しているだ
けである。

3.4

評価

このシステムでは運転状態からレジューム状態に移るまで、平均 3 秒程の時間しかかからない。レジューム状態からの復帰には 1 秒程度かかる。表 3.1にレジューム機能を持たせたシステム起動時間と shutdown の時間の効用を示す。

第 18 部

オペレーティングシステム

715

autoshutdown(){
switch ( notebookid() ) {/* notebook id は、各ノートブック独特の ROM イメージから、機種判定* を行ない、機種名を返すルーチンである。
*/
case DYNABOOKA: /* ダ イナブック タイプ A の場合 */outw(0x0e8, 0x9a5a);
break;
case DYNABOOKB::: /* 機種によって、電源 OFF を行なうルーチンは異なる。*/
case NOTYPE: /* 機種が特定できない */error(機種が特定できない);
break;}/* レジュームした時はここより下はいかないはず! */sleep(3);clockadj(); /* レジューム復帰時にクロックを戻す */}図 3.2: autoshutdown のアルゴ リズム
これに対しレジューム機能を使用しない場合、常に shutdown と、ブートという作業を繰り返すため、起動しているアプリケーションも中断し 、再起動しなければならなくなる。 また shutdown には 40 秒、起動には 110 秒の時間が無駄となり、ノートブックの連続運用性が確保されない。さらにシステムへのログインを行ない、アプリケーションの再起動を行なわなければならなくなるため、実質的な時間の無駄がさらに広がる。本研究によりレジューム機能を UNIX で利用できるようになり、ノートブックの連続運用性が確保された。
一方レジューム時のクロック補正は、現在は単純なクロック補正機能によって、解決している。しかし 、実際には復帰時にクロック補正を行うためレジューム時間内に動作す

表 3.1: レジューム機能の効用

shutdown 時間
1秒
3秒
110 秒
40 秒

システム起動時間
レジューム機能あり
レジューム機能なし

1993 年度 WIDE 報告書

716

pccons.c /* カーネル上のキーボードデバイス処理部 */case RESUMEHOTKEY: /* レジューム のホットキーが入力された場合 */resumestart();
autoshutdown();/* ここまではこない */break;

図 3.3: 特殊キーの組合せによるレジューム
るはずの cron などで時間設定されたプロセスに対しては、それらの動作が無効となってしまう場合があるため、変更を行なう必要があるだろう。また 厳密な意味では、プロセ
ステーブルの実行時間などに影響が現れてしまうため、根本的な UNIX システムの構成を変更しなくてはならなくなる。そのため UNIX の持つ時間軸をゆがめる機能が必要となる。
具体的解決案として、レジューム復帰時に UNIX の持つ時計をハード ウエアクロックの時間まで早送りすることによって、レジューム期間中の at ジョブ、cron ジョブの実行を行なうルーチンを作成する必要がある。
また、プロセステーブルに関していえば 、resume time という新たな変数を置くこと
で、レジューム状態で UNIX システム全体が止まっていた時間を報告するシステムを構築する必要がある。

3.5

まとめ

UNIX でレジューム機能をサポートするために、レジュームを行うキーを対応させ、オ
ペレーティングシステムが、レジューム状態を感知できるよう工夫した。また、シャット
ダウン時にも自動的に本体の電源が切れるようにするといった配慮を行った。
レジュームによる時計の遅れは、ハードウエアクロックとの動機をとるという安易な解決で終ってしまったが、今後、早送り時計などの開発も必要となるであろう。

第 4章
携帯型計算機における UNIX の利用 (2)携帯型計算機においてバッテリーによる期待稼働時間を増加させる方法として、利用していない時は、使っていない部分 (LCD のバックライトや DISK 等) の電源を極力切る
ことで電力消費を押えていく方法がある。また CPU 自体も内部の動作クロックを止めたり、通常動作時に比べて外部から入力するクロックの周波数を変更することなく内部周
波数を下げて、消費電力の低減を計ることが可能なものが存在している。これらは通称、
節電機能と呼ばれている。

4.1

節電機能について節電機能を利用するには計算機が利用されてない (アイドル ) 状態であることをシステ
ムが認識できる機構が必要となる。これには通常オペレーティングシステム側のサポートが不可欠である。

MSDOS ではシステムがアイドル状態であるかどうかを検出する手法として、power.exeという、デバイスド ライバを利用している。power.exe はオペレーティングシステムやBIOS に発する割り込みなどの発生状況を調べる。この結果パソコンがアイドル状態だと判断すると待機状態にはいっても構わないことを MSDOS の電源管理インターフェース
である APM インターフェースを介して直接制御 BIOS に知らせることで節電機能を利用可能にする。
これに対し UNIX では 、BIOS を介さずに 、直接ハード ウエアを制御しているため 、
MSDOS と同様の検出方法を用いることはできない。そこで別の方法でアイドル状態を検出する方法を考えた。

4.2

実装

本研究では、節電ユーティリティとして次のようなコマンドを用意した。ここでは CPUのアイドル状態の検出に X サーバが標準で用意しているスクリーンセーバを用いている。
これは厳密な意味でアイドル状態の検出になっていない部分もあるが携帯型計算機の実際の利用形態を考えた場合、十分実用できであると判断した。

717

1993 年度 WIDE 報告書

718
4.2.1

xsetsudenxsetsuden は 、X ウインド ウ上で動作するユーティリティである。xsetsuden は 、X

ウインドウ実行時に起動する X ウインド ウのスクリーンセーバと連動し 、液晶のバック
ライトの消灯、液晶そのものの電源カット、ハードデ ィスクのアイドルモード、CPU ス
リープ を行なう。X サーバーに改良をし 、X サーバー内の関数 XSetScreenSaver のタ
イムアウトによって、節電機能を作動させる [251]。
xsetsuden によって動作する節電機能は次のような流れで行なわれる。

 X サーバーのスクリーンセーバが起動する。
 同時に液晶のバックライトを消す。
 スクリーンセーバが起動してから 30 秒後にハードデ ィスクを sync、ハードディス
クをアイドルモードにする。(ハードディスクのモータを止める) ハードデ ィスクの電源を切ってから 30 秒後に、CPU をスタンバイモードに移行させる。

xsetsuden の起動間隔は、xset コマンドによって設定できる。
4.2.2

backlight

backlight コマンドで任意にバックライトの消灯・点灯を行うことができる。日常の明るさではバックライトを点灯しなくても、液晶の表示が判読可能な場合が多い。このような時は、バックライトコマンドでバックライトの点灯、消灯を行なうことができる。
バックライトを消灯した場合、画面はかなり見辛くなるが、稼働時間は劇的に増える事
になる。
4.2.3

評価

xsetsuden のタイムアウトを 30 秒で設定し 、実際にバッテリー警告灯が点灯するまで

ノートブックで日常作業を行ってみた (本論文の執筆作業を行った)。通常はバッテリーの充電から 110 分程度の作業が可能だが、xsetsuden による節電効果によって、145 分まで作業時間を伸ばす事ができた。この実験では、作業体系は、ほぼ連続していて、あまりアイドル時間が増えなかったので、稼働時間を効果的に伸ばす事が出来なかったが、節電機能は有効であるというのがわかる。
xsetsuden は X ウインドウ上でしか動作しないため、コンソール状態での節電ユーティ
リティには対応しない。また根本的な UNIX オペレーティングシステムに節電機能を採り入れているわけではないので、その点については改良を行なう必要がある。
また backlight コマンドによって、110 分程度だった稼働時間を 260 分まで伸ばす事が出来た。バックライトによる電力消費を抑えることによって、ノートブックの稼働時間を大幅に増やす事が可能であるというのがわかる。

第 18 部

4.3

オペレーティングシステム

719

まとめ

節電ユーティリティを X ウインド ウに対応させる事で、バッテリーの有効利用が出来るようになった。またユーザが意識することなく節電が行えるよう配慮した。また携帯型計算機での節電に限らず、固定的に運用する通常のワークステーションでも節電機能は重要である。最近は計算機システムもエコロジーへの配慮が必要という意見があり、現にアメリカではエナジースターと呼ばれる節電のための規格がすでに存在している。UNIXもこれに対応する必要が迫られるだろう。
現在、節電機能については、まだ UNIX システムそのものがそれに基づいて考えられていない。今後、新しいシステムを構築する上で、カーネルレベルでの節電|例えば、ハードディスクを出来る限りアクセスしないシステムの開発| 等が重要であると考えられる。
そのためには機器の抽象化とオペレーティングシステムとの融合についても考慮する必要があるだろう。

第 5章
国際化対応マルチバイト 文字処理関数ライブラリの開発
今日、ソフトウエアの国際化は大きな課題の一つとなっている。しかし世界中で使用されている文字コードにはさまざまなエンコーディングがある (日本語だけ考えてもロッ
クシフトを用いた JIS コード、シングルシフトを用いた EUC 、「すき間」を利用したシ
フト JIS 、さらには近い将来 JIS 化されそうな Unicode がある) 。これらすべてに対応するようにプログラミングすることは困難である。
これに対し 、多くのシステムでは複数のエンコーディングに対応するマルチバイト文
字処理のためのライブラリが提供されている。しかし多くは対応しているマルチバイト
文字コードは EUC などごく一部に限られ、ステートフルの文字コードに対応しているものはまれである。またソースが公開されておらず、システムごとのライブラリの仕様の相違が大きいため、国際化対応アプリケーションの移植性を悪いものにしている。
以上のような現状をふまえ、

 現在使われているほとんどの文字コードに対応できる柔軟性がある
 特定のシステムに依存しない フリーソフトウエアとして公開できるという基本的要求を満たすことのできるマルチバイト文字処理関数ライブラリを開発した。

5.1

仕様

実装したライブラリ関数は ISO C マルチバイト拡張仕様案 [252] (以下 MSE と略す。
MSE:Multibyte Support Extension) に従うことにした。MSE の特徴として以下の点があげられる。

 ANSI C 標準ライブラリ関数とほぼ同様のインタフェース ステートフルエンコーディングのマルチバイト文字の処理に対応できるように、文字列やストリームごとのステートを保存する方法が規定されている。

 文字分類/変換関数 (標準ライブラリでいう is*、to*) は分類/変換クラスが拡張可能になっている。

720

第 18 部

5.2

設計

5.2.1

基本構成

721

オペレーティングシステム

ライブラリを構成する関数群を以下のように分類する。

setlocale 関数 環境変数などから現在のロケールを取得し 、ロケール情報 (このライブラ
リでは文字コード、文字分類に関する情報) をファイルからロード する。

ワイド 文字入出力関数群 動作はロケール情報に基づいて行われる。入力関数はマルチバ
イト文字のストリームからバイト列を読み込み、ワイド 文字に変換して格納する。
出力関数はワイド 文字をマルチバイト文字列に変換してストリームに書き出す。
ワイド 文字処理関数群 標準ライブラリの ctype, string 関数のワイド 文字対応版。ctype
関数はロケール情報に基づいて動作を変える。
これらの関数の関係を図 5.1に示す。
User program
Wide functions(isw*, tow*, wcs*)

Wide string

Wide I/Ofunctions(fgetws,fputws,etc)
Internal Multibyte-WIdetranslating function

setlocaleJapanese
ChineseJIS locale EUC locale ...
data
data

XXX
localedata

External locale data files

Byte stream

図 5.1: 国際化対応文字処理ライブラリ関数の階層

5.2.2

マルチバイト 文字コード

既存の文字コードは次のようなエンコーディング方式に分類することができる。
ステートレスなもの EUC 、S-JIS 、BIG-5 など

1993 年度 WIDE 報告書

722

iso2022 ロックシフト に基づいたステートフルなもの JIS 、ISO-2022-JP など
iso10646/unicode に基づいたもの UTF-2 など
iso10646[253]/unicode[254] をそのままサポートすることはあきらめた。なぜならこれらは現在の C 言語の仕様にはなじまないからである。c 言語では文字はバイトの列からなり、値が 0 のバイトはヌルバイトで文字列の終端を表すことになっているが、これらは 1 文字 16 ビット (または 32 ビット ) であり、これを 2 バイト (または 4 バイト ) からな
るマルチバイト文字であると考えるべきではない。例えば `a' は unicode では 16 進数で0041 という値となるが、これでは文字列の途中でヌルバイトが入ってしまうことになる。
5.2.3

ワイド 文字コード

ワイド 文字コードは以下の条件を満たしていることが望ましいと考えられる。

 ステートレス
 1 文字の長さが固定
 サポートするすべてのマルチバイト文字コード のスーパーセット
現段階でこれらの条件を最も満たしている文字コードとして、本研究では icode[255] を選択した。これは iso10646/unicode を基にしたものだが日中韓の漢字の区別のためのビットが付加されている。icode は結合文字が存在するため 1 文字固定長とはいえない面もあるが、結合文字を使用することは少なく、文字処理に影響することはあまりないだろう
と考えた。

5.3

実装

実装は BSD/386 で行った。BSD/386 は BSDI 社の開発した POSIX 互換のオペレーティ
ングシステムで University of California Berkeley (UCB) の CSRG (Computer Systems
Research Group) の開発した BSD Networking Software, Release 2(NET/2) を基に開発されたものである。BSD/386 はカーネルを含むシステムソフトウェアの殆どがソースコー
ドを含めて入手可能であり、今回実装を行うのに最適なシステムの一つだと考えられる。
5.3.1

マルチバイト$ワイド 文字変換

このライブラリでもっとも重要な部分は入出力関数、拡張マルチバイト /ワイド 文字変
換関数内部で用いられるマルチバイト ワイド 文字変換ルーチンである。
変換アルゴ リズムとしては大きく分けて$

1. 一定の演算やビット操作によって変換する方法
2. マルチバイト文字とワイド 文字とのマッピングテーブルによって変換する方法

第 18 部

オペレーティングシステム

723

が考えられるが、このライブラリの場合ワイド 文字コードが icode のため EUC などとは
コード の並びが全く異なる。そのため演算やビット操作による方法では効率よく変換することができない。それでマッピングテーブルによる方法を用いることにした。マッピ
ングテーブルは各ロケールのロケール定義ファイルに記述され、setlocale 関数の呼び出
しで読み込まれる。
マッピングテーブルを用いる場合、メモリ消費が問題となる。 2 バイトコードの値をそのままテーブルのエントリ番号 (つまり配列の添字) として与えるとすると、216 = 65536
エントリが必要になる。ワイド 文字 (wchar t) は 4 バイト長なので、1 つのテーブル全体の大きさは 65536 4 バイト =256K バイトとなる (マルチバイト ワイド 変換とワイド
マルチバイト変換の 2 つのテーブルが必要である) 。さらにマルチバイト文字が 3 バイト
コード の場合は 64 メガバイト、4 バイトコードなら 4 ギガバイトとなる。ここまでいくととても現実的な値ではなくなる。
しかし実際にはコードのすべての部分が使われているわけではない。例えば日本語 EUC
コードは最大 3 バイトであるが、文字が割り当てられている部分を各バイトをそれぞれ
xyz 軸に割り当てて 3 次元の空間として表現するとほとんどが空きであることが分かる(図 5.2)。

2!

!

1st byte
ff

ff

00

2nd byte
ASCII

7e
a1

JISX0201df
ff
3rd byte

JISX0212
JISX0208

8ea1

f4

図 5.2: 日本語 EUC のコード 割り当て空間
それでテーブルは文字が連続的に割り当てられている範囲ごとに作成することにした。
このようにすると日本語 EUC のマルチバイト ワイド 文字変換テーブルの大きさは 60K
バイト弱となった。また compoundtext の場合でも約 110K バイト、UTF-2 だと約 118K
バイトになった。
ワイド マルチバイト文字変換テーブルもほぼ同様の考え方で作成することにしたが、ワイド 文字コード (icode) ではもともと unicode で日中韓の漢字が統合されて割り当てら!

!

1993 年度 WIDE 報告書

724

れていたものに日中韓の識別ビットをつけてそれぞれの国の漢字を判別するようになっている。そのため unicde では日本の漢字にはなくても中国や韓国の漢字には存在する文字に割り当てられているコードが、icode で日本の漢字が割り当てられている部分では空きになってしまう。このように不連続な空きが多いため、上手にテーブルを分割することができなかった。そのためワイド マルチバイト文字変換テーブルはマルチバイト文字コードに日中韓のいずれかの漢字コードが含まれる場合、200 K バイトを越える大きさになってしまった。これを解決するためにはワイド 文字コード とテーブルのデータ構造の変更が必要である。

!

5.3.2

ワイド 入出力関数!

入出力関数は、内部でマルチバイト ワイド 文字変換を行なうとともに、ストリーム
ごとのステートを保存しなければならない。ステートの保存のために mbstate t という新しい型が定義されている。ストリームごとにステートを保存するためには le 構造体に
mbstate t 型のメンバを付け加えるのがもっともスマートな方法だと考えられるが、こうすると標準ライブラリ関数にまで影響が及ぶのでファイルディスクリプタ番号をエント
リ番号にとる、ステート保存用の別のテーブルを用意した。

5.3.3

ワイド 文字分類・変換関数

MSE では文字分類・変換クラスの拡張ができるように、wctype 、iswctype 、wctrans 、
towctrans という 4 つの関数を定義している。これらは例えば以下のように用いることができる。

wchar_t wc, wc2;
int n;
n = iswctype(wc, wctype("hiragana")); /* wc がひらがなだったら真 *//* wc がひらがなだったら、wc2 にはカタカナが入る */wc2 = towctrans(wc, wctrans("tokatakana"));
この例の \hiragana" 、\tokatakana" というクラス名とその対象となるコード の範囲、変換先はロケール定義ファイルに記述される。

5.3.4

ワイド 文字列処理関数

ワイド 文字列処理関数はロケールには影響されない (wcscoll 、wcsxfrm 、wcsftime を除く) ので標準ライブラリの関数の名前を str*だったものを wcs*に変え、char 型だった引数の型をワイド 文字型 (wchar t) に変えるだけでよい (実際にはスクラッチから書いた) 。

第 18 部
5.3.5

オペレーティングシステム

725

ロケール定義ファイル

文字コードに依存する情報はほとんどロケール定義ファイルに記述することができる。
現在用意されているのは 5.3.6節にあげたものだけだが、ロケール定義ファイルを用意することによって新たな文字コードに対応させることができる。
ロケール定義ファイルは${LOCALEDBPATH}/{ロケール名}/LC_CTYPE というファイル名になる。$LOCALEDBPATH はデフォルトでは /usr/local/lib/locale である。ロケール定
義ファイルには以下のような情報を記述する。

 エンコーディングはステートフルかステートレスか ステートフルの場合はエスケープシーケンスに関する情報 コード セットごとのコード 範囲と 1 文字のバイト数
 マルチバイト$ワイド 文字変換マッピングテーブル
 文字分類・変換クラス名とそのクラスに関する情報
ロケール定義ファイルはテキスト形式で記述できるが 、読み込みの高速化のため、バイナリ形式に変換しておくことにした。そのために mklcctype というユーティリティを
用意した。
5.3.6

対応できた文字コード

現在ロケールデータが作成済みのマルチバイト文字コードは以下のとおりである。
ロケール名

文字コード
日本語 7 ビット jis
日本語 EUC中国語 gb2312
中国語 EUC
韓国語 ksc5601
韓国語 EUC

ja jp.jis7
ja jp.eucjp
zh cn.gb2312
zh cn.eucchko kr.ksc5601
ko kr.euckr
ja jp.utf2
UTF-2

また compoundtext を使うロケールデータもほぼ完成している
5.3.7

用意されている関数

MSE に規定されている関数のうち、図 5.1 、5.2、5.3のものが実装済みである。また現時点では図 5.4のものはまだ未実装である。

1993 年度 WIDE 報告書726

表 5.1: 実装済みの関数{1ヘッダ<iso646.h> 代用スペル

マクロ

and
and eqbitand
bitor
compl
not
not eqoror eq
xor
xor eqヘッダ<wctype.h> ワイド 文字分類、変換関数群型

wctrans t
wctype t
wint t
マクロ

WEOF
関数

int iswalnum(wint t wc);
int iswalpha(wint t wc);
int iswcntrl(wint t wc);
int iswdigit(wint t wc);
int iswgraph(wint t wc);
int iswlower(wint t wc);
int iswprint(wint t wc);
int iswpunct(wint t wc);
int iswspace(wint t wc);
int iswupper(wint t wc);
int iswxdigit(wint t wc);
wctype t wctype(const char *property);
int iswctype(wint t wc, wctype t desc);
wint t towlower(wint t wc);
wint t towupper(wint t wc);
wctrans t wctrans(const char *property);
wint t towctrans(wint t wc, desc);意味&& の代用&= の代用
& の代用
| の代用
~ の代用
! の代用
!= の代用|| の代用|= の代用^ の代用^= の代用意味
ロケール特有の文字変換を表現
ロケール特有の文字分類を表現
WEOF を保持できる型
意味

end-of- le
機能isalnum のワイド 文字版
isalpha のワイド 文字版
iscntrl のワイド 文字版
isdigit のワイド 文字版
isgraph のワイド 文字版
islower のワイド 文字版
isprint のワイド 文字版
ispunct のワイド 文字版
isspace のワイド 文字版
isupper のワイド 文字版
isxdigit のワイド 文字版
ワイド 文字分類クラスの値を返す
拡張ワイド 文字分類関数
tolower のワイド 文字版
toupper のワイド 文字版
ワイド文字変換クラスの値を返す
拡張ワイド 文字変換関数

第 18 部

オペレーティングシステム

727

表 5.2: 実装済みの関数{2ヘッダ<wchar.h> 拡張マルチバイト /ワイド 文字関数群型

mbstate tマクロ

WCHAR MAXWCHAR MIN
関数
・ワイド 文字入出力関数

wint t fgetwc (FILE *stream);wchar t *fgetws (wchar t *s, int n, FILE *stream);
wint t fputwc (wint t c, FILE *stream);
int fputws (const wchar t *s, FILE *stream);
wint t getwc (FILE *stream);
wint t getwchar(void);
wint t putwc (wint t c, FILE *stream);
wint t putwchar(wint t c);wint t ungetwc (wint t c, FILE *stream);
int fwide (FILE *stream, int mode);・拡張マルチバイト /ワイド 文字変換関数

wint t btowc (int c);
int wctob (wint t c);意味
変換ステートの保持意味
wchar t の最大値
wchar t の最小値
機能

fgetc のワイド 文字版
fgets のワイド 文字版
fputc のワイド 文字版
fputs のワイド 文字版
getc のワイド 文字版
getchar のワイド 文字版
putc のワイド 文字版
putchar のワイド 文字版
ungetc のワイド 文字版
ストリームのオリエンテーショ
ン変更

1 バイトをワイド 文字へ変換
ワイド 文字を 1 バ イト文字へ変換
ps が初期状態か調べる
mblen の \restartable" 版
mbtowc の \restartable" 版

int mbsinit (const mbstate t *ps);size t mbrlen (const char *s, size t n, mbstate t *ps);size t mbrtowc (wchar t *pwc, const char *s, size t n, mbstate t *ps);size t wcrtomb (char *s, wchar t wc, mbstate t *ps);
mctomb の \restartable" 版size t mbsrtowcs(wchar t *dst, const char **src, size t len,mbstate t *ps);
mbstowcs の \restartable" 版size t wcsrtombs(char *dst, const wchar t **src, size t len,mbstate t *ps);
wcstombs の \restartable" 版1993 年度 WIDE 報告書

728

5.4

問題点

 ロケールデータの保持のためのメモリ消費量が大きい。JIS コード 用で約 280K バイ
ト、UTF-2 用で約 460K バイト消費する。このうちの 70〜80%がワイド !マルチバ
イト文字変換テーブルに消費されている。

 システム付属のマルチバイト文字処理関数と比べてマルチバイト!ワイド 文字変換速度が遅い。これはシステム付属のものがたいていマルチバイト文字コードが EUC 、
ワイド 文字コード も EUC の変形でほとんど 変換に手間がかからないのに対し 、このライブラリでは変換にかなりの処理が必要なためだと考えられる。

 対応しきれないマルチバイト文字コードがある。たとえば ISO-2022-INT-1 は GB2312
中国語と CNS11643 中国語の文字コードを区別しているが、ICODE ではこれらは統合されて中国語のコードとして割り当てられているためワイド 文字に変換すると区別できなくなってしまう。

5.5

今後の課題

まずまだ実装を終えていない関数の実装と BSD/386 以外のシステムで利用できることの確認を行ない、公開する予定である。ライブラリの次の課題としては以下のようなものがあげられるだろう。
よりよいワイド 文字の設計 日本語、中国語、韓国語を扱う場合、無駄が多いことなどを考えるとワイド 文字コードの改良が必要である。また結合文字への対応も考慮したい。
アプリケーションへの適用 このライブラリを利用した応用アプリケーションの開発を行
い、有用性を検証する必要がある。
高レベルライブラリの国際化 curses や regex 、dbm などをこのライブラリに対応可能なように改良する。
コンパイラへの適用 プログラム中にワイド 文字定数を利用可能にし 、プログラムの可読性を上げる。

第 18 部

オペレーティングシステム

表 5.3: 実装済みの関数{3関数・ワイド 文字列関数

wchar t *wcscpy (wchar t *s1, const wchar t *s2);
wchar t *wcsncpy (wchar t *s1, const wchar t *s2, size t n);wchar t *wcscat (wchar t *s1, const wchar t *s2);
wchar t *wcsncat (wchar t *s1, const wchar t *s2, size t n);
int wcscmp (const wchar t *s1, const wchar t *s2);
int wcsncmp (const wchar t *s1, const wchar t *s2, size t n);wchar t *wcschr (const wchar t *s, wint t c);size t wcscspn (const wchar t *s1, const wchar t *s2);
wchar t *wcspbrk (const wchar t *s1, const wchar t *s2);
wchar t *wcsrchr (const wchar t *s, wint t c);size t wcsspn (const wchar t *s1, const wchar t *s2);
wchar t *wcsstr (const wchar t *s1, const wchar t *s2);
wchar t *wcstok (wchar t *s1, const wchar t *s2, wchar t**ptr);
size t wcslen (const wchar t *s);機能

strcpy のワイド 文字版
strncpy のワイド 文字版
strcat のワイド 文字版
strncat のワイド 文字版
strcmp のワイド 文字版
strncmp のワイド 文字版
strchr のワイド 文字版
strcspn のワイド 文字版
strpbrk のワイド 文字版
strrchr のワイド 文字版
strspn のワイド 文字版
strstr のワイド 文字版
strtok のワイド 文字版
strlen のワイド 文字版

729

730

1993 年度 WIDE 報告書

表 5.4: 未実装の関数
関数・ワイド 文字入出力関数

機能

int fwprintf (FILE *stream, const wchar t *format, ...);
int fwscanf (FILE *stream, const wchar t *format, ...);
int wprintf (const wchar t *format, ...);
int swscanf (const wchar t *s, const wchar t *format, ...);
int wscanf (const wchar t *format, ...);
int swprintf (wchar t *s, size t n, const wchar t *format, ...);
int vfwprintf(FILE *stream, const wchar t *format, va listarg);
int vwprintf (const wchar t *format, va list arg);
int vswprintf(wchar t *s, size t n, const wchar t *format,
va list);fprintf のワイド 文字版
fscanf のワイド 文字版
printf のワイド 文字版
sscanf のワイド 文字版
scanf のワイド 文字版
sprintf のワイド 文字版
vfprintf のワイド 文字版
vprintf のワイド 文字版
vsprintf のワイド 文字版

・ワイド 文字列数値変換関数

double wcstod (const wchar t *nptr, wchar t **endptr);
strtod のワイド 文字版
long int wcstol (const wchar t *nptr, wchar t **endptr, int strtol のワイド 文字版base);
unsigned long int wcstoul(const wchar t *nptr, wchar t strtoul のワイド 文字版**endptr, int base);・ワイド 文字列関数

int wcscoll (const wchar t *s1, const wchar t *s2);
int wcsxfrm (const wchar t *s1, const wchar t *s2, size t n);
size t *wmemchr (const wchar t *s, wchar t , size t n);
int wmemcmp (const wchar t *s1, const wchar t *s2, size tn);wchar t *wmemcpy (wchar t *s1, const wchar t *s2, size tn);wchar t *wmemmove(wchar t *s1, const wchar t *s2, size tn);wchar t *wmemset (wchar t *s, wchar t, size t n);
size t wcsftime(wchar t *s, size t max, const wchar t *format, const struct tm *timeptr);

strcoll のワイド 文字版
strxfrm のワイド 文字版
memchr のワイド 文字版
memcmp のワイド 文字版
memcpy のワイド 文字版
memmove のワイド 文字版
memset のワイド 文字版
strftime のワイド 文字版

第 6章
新しいコンセプト の OS の紹介
現在、標準 OS として広く普及している UNIX は、仮想メモリ機能、TCP/IP ネット
ワーク機能などの様々な機能が加えられ発達してきたが、基本設計が 20 年以上も前になされたもののため、新しいハードウェア、ソフトウェアモデルに必ずしも合わなくなってきてきる。
そこで新しいコンセプトにもとづく OS が提案されている。例えば 、Sun 社の Springをはじめとするオブジェクト指向 OS などが研究レベルで提案されている。
今回紹介するのは、64 ビットプロセッサで提供しうる 64 ビットの広大な仮想アドレス
空間を積極的に利用した SASOS(Single Address Space OS) と呼ばれる OS である。

6.1

Cubix

Cubix[256, 257] は 64 ビットプロセッサでの利用を想定し 、単一の広大なアドレス空間(264 ＝ 16 エクサバイト ) を利用し 、かつ、プログラム (UNIX でいうところのプロセス)とファイルを区別することなく、その空間中にすべて配置するメモリモデルが特徴である。このモデルによって、従来システムコールを介して行われる IPC (プログラム間通信) やファイルアクセス (read, write など ) を、Cubix ではメモリアクセスの形で直接行なえるので、OS のオーバヘッドが低下し 、高速なプログラム実行を可能とする場が提供できる。
また、従来プログラムごとに独立な仮想記憶空間を割当て、空間の独立性でプログラムを保護してきたが 、Cubix では空間とは独立した保護概念を導入し 、同一アドレス空間内でもメモリ保護を可能とした。これは、ページ単位の保護機構で、メモリ管理機能(MMU) に多少の拡張をすることによって、より高速に機能するように考えられている。
Cubix は以下の特徴をもつ。

1. 単一仮想記憶空間 (SVS) の採用
UNIX などの OS では、プログラムごとに仮想記憶空間が割り当てられ 、互いに空間が独立している多重仮想記憶空間 (MVS) 方式であるが、Cubix ではすべてのプロ
グラムやデータが共通の単一仮想記憶空間中に存在する（図 1 ）。
この SVS の導入により、プログラム間の通信は、メモリポインタの受け渡しとサブ
ルーチン呼び出しで行える。

731

732

1993 年度 WIDE 報告書

図 6.1: 仮想空間構成概念図

2. 高機能メモリ保護機構を用いたアクセス保護
仮想空間は複数のメモリセクションと呼ぶ領域から構成される。各メモリセクショ
ン毎に「スレッド ID 」と「現在スレッドが実行しているプログラムの存在するメモ
リセクション ID 」の２つをキーとして readable/writable/executable の各属性を指定することにより、メモリセクションに対するアクセス保護を設定する。ここでスレッド ID がキーとして加わっているため、共通の単一仮想記憶空間でありながら、
スレッドごとに参照可能なメモリセクションが異なり、スレッド 間のアクセス保護が実現できている。

3. 一元化記憶域 (OLS) の採用
ディスク上のデータとメモリ中のデータを区別なくアクセスできるように、すべてを仮想記憶空間中に存在させる。
ディスクに格納されているファイルは、Cubix ではメモリセクションに対するバッキングストアとなる。物理メモリは、実体に対するキャッシュとして扱う。この点
で Cubix のメモリセクションは Mach[258] におけるメモリオブジェクトと類似の概念である。

4. マイクロカーネルアーキテクチャ
Cubix は、マイクロカーネルアーキテクチャ構成を採用している。したがって、Cubix
マイクロカーネルの上に UNIX サーバなどの各種システムサーバをのせ、柔軟な OSの構成ができるようにした。この形で既存の各種 OS との互換性を提供する。Cubixの全体構成を図 6.1に示す。

第 18 部

6.2

オペレーティングシステム

733

Opal

ワシントン大学では、Opal という Cubix と同様な単一仮想記憶空間方式の OS を開発している [259]。
保護方式は、単一仮想空間上にプロテクション・ド メインと呼ぶ保護単位の領域を多重に重ねることにより、スレッド、プログラムの保護を行うものである。
Cubix のモデルでは 、保護をより柔軟にするためにスレッド ID とメモリセクション
ID の２つの保護キーにより保護を実現しているが、Opal では、従来のコンテクスト IDと同様な考え方で、一つのキー（プロテクション・ド メイン ID ）で保護している。したがって、OS の実装にあたっては、特殊なハードウェアを仮定していないがそのままではUNIX の fork の概念がサポートできないという欠点がある。

6.3

おわりに

以上、Cubix を中心にして、簡単に SASOS について報告した。Cubix は、現在。機能検証モデルとして、32 ビットの DOS マシン上にプロトタイプが動作している [260]。今後は、高速ネットワークに適合した OS として発展させる予定でいる。
携帯型の個人情報機器、マルチメディア、高速ネットなどの OS をとりまく環境は、時代とともに変化している。今後とも、新しい計算機環境に適した OS がいろいろ登場するだろう。UNIX をはじめ、このような OS の動きにも注目し 、積極的に WIDE 環境に取り入れていくことが必要であろう。

734

1993 年度 WIDE 報告書

図 6.2: Cubix 構成概念図