マリスト 1 usbdaq ドライノぐ #include く sys/param. h> #include く sys/systm. h> 2 : #include く sys/kernel . > 3 : #if defined(——NetBSD__) Ⅱ defined(——OpenBSD 4 : #include く sys/device . h> 5 : #elif defined(——FreeBSD 6 : く sys/module . > 7 : #include く sys/bus . h> 8 : #include 9 : #endif く sys/conf . h> 10 : #include く sys/vnode. h> 11 : #include 12 : く dev/usb/usb. h> 13 : # include く dev/usb/usbdi . h> 14 : # include く dev/usb/usbdi—util . h> 15 : # include く dev/usb/usbdevs . h> 16 : # inc 1ude 17 : 18 : #ifdef USBDAQ_DEBUG #define DPRINTF(x) 19 : logprintf x #define DPRINTFN(n, x) 20 : (n) ) logprintf x 21 : int usbdaq-debug = 0 ; 22 : #else DPRINTF(x) 23 : #def ine x) DPRINTFN (n , 24 : #define 25 : #endif 26 : USBDAQUNIT(n) 27 : #def ine > > 1 ) & 0xf) USBDAQALTEP ( Ⅱ ) 28 : #def ine USBDAQMINOR(u, a) 29 : #def ine 30 : 31 : #define USBDAQ_BSIZE 32 : #define USBDAQ_NEP # of endpoints * / 33 : #def ine USBDAQ_NEP_BULK IN 2 bulk—in endpoints 34 : #define USBDAQ_BULKOUT 35 : #define USBDAQ_BULKIN 36 : #def ine USBDAQ_ALT_BULKIN 2 37 : #def ine USBDAQ_TIMEOUT 38 : struct usbdaq—softc { 39 : 40 : USBBASEDEVI CE usbd_device_handle S C 42 : usbd_interface_handle 43 : 44 : 45 : 46 : 47 : usbd_xf er_handle 48 : char s c— sbuf CUSBDAQ -BS 工 ZE] ; 49 : usbd_xfer_handle 50 : char sc—alt—sbuf [USBDAQ-BSIZE] ; 51 : 52 : 53 : 54 : 55 : 56 : 57 : 58 : 59 : 60 : 61 : 62 : 63 : 64 : d—open—t usbdaqopen ; d_close_t usbdaqclose ; d_read_t usbdaqread; d—write_t usbdaqwrite ; #def ine USBDAQ_CDEV_MAJOR 200 Static struct cdevsw usbdaq—cdevsw = { / * open * / usbdaqopen , close * / usbdaqclose , / * read * / usbdaqread , write * / usbdaqwrite , ioctl * / noioctl, / * P011 * / Ⅱ 0P011 , / * mmap * / nommap, strategy * / nostrategy, name * / " usbdaq" / * maj * / USBDAQ—CDEV—MAJOR, / * dump * / nodump , / * psize * / 110PSIZe , / * flags * / / * bmaj * / 65 : 66 : 67 : 68 : 69 : 70 : 71 : 72 : 73 : 74 : 75 : 76 : 77 : 78 : 79 : 80 : 81 : 82 : 83 : 84 : 85 : 86 : 87 : 88 : 89 : 90 : Static usbd—status usbdaq_open_pipe (struct usbdaq—softc * ) ; Static void usbdaq—close-pipe(struct usbdaq-softc 91 : 92 : Static usbd_status usbdaq—bulk—xfer(usbd—xfer-handle, usbd-pipe_handle , 93 : u—int32_t * ) ; 94 : Static void usbdaq-bulk—xfer—cb(usbd-xfer-handle , usbd—privat e—handl e , 95 : usbd—status) ; Static usbd—status usbdaq_reset (struct usbdaq_softc 96 : if (usbdaq-debug) if (usbdaq—debug > #endif ( (minor(n) (minor(n) & 1 ) VOid * , 1024 3 0 1 97 : Static int usbdaq—do—read(struct usbdaq_softc * , 98 : uiO * , int); struct Static int usbdaq—do—write (struct usbdaq_softc * , 99 : uiO * ) ; struct 100 : 101 : 102 : 103 : 104 : 105 : 106 : 107 : 108 : 109 : 110 : 111 : >device) ; 112 : 113 : UGETW ( dd- > idVendor ) 114 : USB_VENDOR_KEI SOKUG IKEN & & UGETW(dd->idProduct) 115 : USB_PRODUCT_KEI SOKUGIKEN_USBDAQ ) return (UMATCH-VENDOR_PRODUCT) ; 116 : 117 : return (UMATCH_NONE) ; 118 : 119 : 120 : 121 : 122 : 123 : 124 : 3000 USB_DECLARE_DRIVER(usbdaq) ; USB_MATCH (usbdaq) USB_MATCH_START ( usbdaq , uaa) ; usb—device—descriptor—t *dd; SC_deV; sc_iface; s c -pipe [USBDAQ—NEP] ; sc-epaddr [USBDAQ—NEP] ; S C xfer; usbd—pipe ー handle u_int8_t if ( !uaa—>iface) return (UMATCH_NONE) ; dd = usbd—get—device—descriptor(uaa— sc_xfer _alt ; sc—is—open CUSBDAQ—NEP_BULKIN] ; sc_refcnt ; sc—dying; char int char #if defined(——FreeBSD__) dev_t dev; USB_ATTACH (usbdaq) USB_ATTACH_START(usbdaq, sc , uaa) ; usb—endpoint—descriptor—t *ed; #endif #if defined(——NetBSD__) Ⅱ defined(--OpenBSD——) cdev—decl (usbdaq) ; #elif defined(——FreeBSD__) 166 ー BSD magazine 2000 NO. 6

OR-OSARCH は 良い。 で gcc をインストールするようにすれば のインストールを最優先し、同じ指定 アーキテクチャをサポートした binutils は発生しない。この場合は正しい CPU えば動かすことができるのでこの問題 リンカスクリプトを自分で書いてしま チャさえあっていれば、あとは crt0. s と ラムを書く場合には CPU のアーキテク ROM から自分で焼いてしまう ) プログ 完全に組み込んでしまう ( プート ーマットなど ) が必要になるためだ。 有のフォーマット ( 実行バイナリフォ スクリプトをはじめ OS ゃべンダーに特 しないのに対して、リンカにはリンカ イラには CPU 以外の要素はあまり関係 はエラーとなる。これは主に c コンパ 許されるが binutils のインストール時に ターゲットは gcc のインストール時には とえば、 mipsel-unknown-netbsd という テクチャに違いがある場合がある。た ートしている CPU 、べンダー、アーキ ちなみに binut ⅱ s と gcc との間でサポ 中にエラーになるので注意しよう。 合 " dec " 以外の文字をいれると configure ゲットである MIPS CPU 、 NetBSD の場 ファイルをみるとわかる。今回のター binuti1s-2.10/1d/configure ・ tgt OSARCH はターゲット環境のオペレ ーティングシステム、または出力オプ ジェクトフォーマットを指定する。今 回のターゲットはもちろん netbsd であ る。 binutils のインストール いのでこのまま通す。 も可能だが、今回は特にその必要もな ジに若干の修正をいれて変更すること これが気に入らない場合にはパッケー トリにインストールされることになる。 local/mipsel-dec-netbsd というディレク れる。またランタイムライプラリは /usr/ local/bi ⅳにこの名前でインストールさ prefix 等の指定をしない場合には / usr / mipsel-dec-netbsd-as となり、特別に よばす。今回の場合、アセンプラは トール終了後のコマンド名に影響をお ということになる。この名前はインス ¯target=mipsel—dec—netbsd ンへの指定は つまり今回の場合、 --target オプショ さて、 こまでのことがわかれば binutils のインストールは簡単である。 まず、 binutiIs-2.10. tar. gz を持ってき たあと、 % tar zxvf binuti1s-2.10. tar ・ gz として展開する。ディストリピュー ョンのディレクトリを汚すと後々別の クロス環境を構築するときに面倒なの 、ここは mipsel というディレクトリ で を作成し 、ここに gcc 、 binutils という ディレクトリを作成することにしよう。 具体的な手順は以下のようになる。 % mkdir mipsel % mkdir mipsel/binutils その後作成したディレクトリに移動 し、画面 2 のように configure & make を 実行するとクロスアセンプラ、リンカ、 その他バイナリツールー式の作成が完 了となる。 gcc のインストール クロス gcc の作成は binutils より少し だけ厄介である。というのは、 gcc の中 に含まれているランタイムライプラリ をコンパイルするためのヘッダーファ イルを用意してやらなくてはならない からだ。 ますは、 NetBSD のソースから include. tar. gz と sys. tar. gz を持ってくる。 binutils がインストールされていれば、 /usr/ local/mipsel-dec-netbsd/ というディレク トリができているはすなので、 include. tar. gz と sys. tar. gz をここに展開する。 % cd /usr/local/mipsel—dec—netbsd % tar zxvf include. tar ・ gz % tar zxvf sys ・ tar ・ gz ン .. /.. /binuti1s—2.10/configure ——target=mipsel—dec—netbsd a11 install 画面 2 configure & make を実行 # make % make cd include ー S . /sys/sys sys . /sys/arch/mips/include mips . /sys/arch/hpcmips/include machine 画面 3 シンボリックリンクを作成する 026 BSD magazine 200() NO. 6

BSD でゲームを ったかのように、元の関数の実行に戻る注 4 。 たとえば、普段何気なく使用している ki Ⅱプログラムも 実は SIGTERM なるシグナルをプロセスに送っているに過 ぎない。ちなみに、デフォルトでは SIGTERM はプロセス を終了するという処理が当てがわれているので、プログラ ムが強制終了する。どのようなシグナルが用意されている のかは、 man signal で見ることができるので一度眺めてみ るとよいだろう。 こでは、 SIGALRM という割り込みを使用する。この シグナルは setitimer() という関数とペアになっており、 setitimer() で設定した時間が経過すると割り込みが発生す しかし、もしフレーム処理がフレーム時間に比べ無視で きないくらい時間がかかってしまうとしたらどうなるだろ る。この SIGALRM を使ったサンプルプログラムをリスト 1 うか ? 処理がフレーム時間に比べて遥かに早く終了する に例として示した。 ならば、確かにほば一定の同期が取れるだろう。しかし、 signal( ) 関数はシグナルに対応するハンドラを設定する関 フレーム処理には描画処理がどうしても含まれ、実際の描 数である。ハンドラとは割り込みがあったときに実行され 画速度は無視できるほど早くはない。また、フレーム処理 る関数のことで、 SIGALRM のデフォルトでは terminate 自体も CPU 時間を必要するので、この方式では処理が重 pr 。 cess が割り当てられている。もちろん、このままでは意 くなったりすると、どんどん時間がずれてしまうという問 味がないので、ここではハンドラを別のモノに置き替えて 題がある ( 図 2 ) 。 しまおう。 なんとか一定時間毎にフレーム処理を実行することはで setitimer() が SIGALRM を発生させるタイミングを決める 関数である。この時間はマイクロ秒単位で設定できるのだ きないのだろうか ? 実はこのような機能を実現するため に便利な仕組みが BSD には存在する。それは一定時間間 こでは 1 秒とした。通常は一度割り込みが発生する とタイマは除かれてしまい、次の割り込みは明示的に指定 隔でシグナルを発生させるタイマ割り込みである。 シグナルというのは割り込み要求をプロセスに送り、通 するまで発生しないのだが、 setitmer() の引数の it_interval に値を代入しておくことにより、連続的に割り込みを発生 常のプログラム処理を中断させ、別の関数を実行するもの である。関数から処理が抜ければ、プログラムは何もなか させることがてきる こではこれを利用し、あたかも ハックしよう / いう方式である。これならば CPU を無駄にコキ使うという ことはない。 main() while(l){ sleep(l) ; / * フレーム処理 * / マリスト S 給 ALRM のサンプルプログラム itval interval . tV_sec itva1 illterval . tv_usec itval . it_value . tv_ sec itval . it value . tV I.IS e C signal (SIGALRM , al—hundler) ; setitimer(ITIMER REAL, &itval , &itoval) ; #include く stdio . h> #include く sys/time. h> #include く signal . h> void al—hundler (int sig) でフレーム処理はしない * / / * こ while(l){ sleep ( 999999 ) ; / * フレーム処理 * / time (NULL) ; time_t t fprintf (stdout , ctime(&t) ) ; バッフアをフラッシュ * / fflush(stdout) ; main ( ) time_t t ; itimerval itval ; struct itimerval itoval ; struct / * タイマ設定 1 秒毎 * / 注 4 このため、ありとあらゆる場所で呼ばれる可能性があるので、副作用のあるプログラムを記述しないように気をつけなければならない。 187 2000 No. 6 BSD magazine

日 SD を組み込当、イノ こんな感じだ。更に include 以下にター ゲット環境として、 sys 、 mips 、 machine というシンポリックリンクを作成する ( 画面 3 ) 。 主に machine/ansi. h を include するライ プラリに対する処置だ。リンク先はタ ーゲットとなる CPU や OS によって異な るので注意してほしい。 こまでの準備ができたらあ さて、 とは binutils と同様に画面 4 のようにす ればインストール完了である。 --with- newlib オプションは組み込み用のライ プラリ newlib を使う場合に _eprintf と いう関数カ snewlib と libgcc とでノヾッティ ングしてしまうのを避けるオプション である。最終的にはカーネルには libkern. a を、ユーザーアプリケーション には NetBSD のライプラリを使うのだ が、ファームウェアを書いたりする場 合のことを考えて newlib も作っておく ためにつけた。また、 --enable-langu ages=c オプションは Fortran 77 や c + + 、 それに Object - c などをコンパイルして いると時間とディスクがもったいない のでつけておいた。これらのコンパイ —enable—languages=c , c + + ラが必要な方は などとする。ちなみに以前使われてい make LANGUAGES=" c c + + " という方法は、現在では使えなくなっ ている一一逆に古いバージョンは --enable-languages カ使えない 注意してほしい。 デバッガのインストール ので デバッガのインストールも基本的に はアセンプラやコンパイラと何も異な るところはない。画面 5 のようにすれば さて、 良い。 開発」に関連するツールはだいたいそ こまでで一般的な「クロス 各種ツールのインストール 必要がある。 config コマンドは普通 るため、 NetBSD のものを持ってくる ァイルの記述方法や定義方法が異な NetBSD と FreeBSD において con ⅱ g フ ・ config で、以下のツールを作る必要がある。 でも NetBSD カーネルのクロス開発なの ろったことになるが、テーマはあくま に make とするだけでコンパイルでき ・ make NetBSD の make も FreeBSD の make も 元々は同じ pmake であるが、現在で はその実装は微妙に異なっている。 そのため NetBSD のカーネルをコンパ イルする場合には NetBSD のものを持 ってきたほうが簡単なのだ。 make コ マンドのコンノヾイルは、 usr/src/usr. bin/make ディレクトリにある Make file. boot ファイルを使って、 % make —f Makefi1e . boot とすればオッケーだ。 ・ mkdep カーネルのコンパイル時に make depend を行うが、その際に呼び出さ れるツール。やはりこれも NetBSD の ものを使うと間違いがない。 さらに、コンパイルは必要ないがイ ンストールしておく必要のあるファイ ルとして、 NetBSD の /usr/share 以下の ファイルがある。 、こには Makefile の % tar zxvf gcc ー 2.95.2. tar ・ gz % mkdir mipsel/gcc % cd mipsel/gcc . /.. /gcc-2.95.2/configure —target=mipsel—dec—netbsd —with—newlib % make a11 # make install % tar zxvf gdb—5.0 % mkdir mipsel/gdb % cd mipsel/gdb . /.. /configure % make # make install 画面 4 gcc のインストール 画面 5 デバッガのインストール —target=mipsel—dec—netbsd —enable—languages=c 2000 NO. 6 BSD magazine 027

ーセキュリティと 暗号技術を考える 0 やハッシュアルゴリズムの詳細につい て把握するのは困難である。また ssl の デバッグを行う場合、 tcpdump などを 用いたネットワークデバッグの手法は データ内容が暗号化されているため使 えない。そこで用いるのが sslproxy であ る。 sslproxy に関しては、以下の URL を参照してもらいたい。 make を行うこ とで、通常の sslproxy として使用する ことが可能となる ( 画面 3 ) 。 http : //www. obdev. at/Products/ sslproxy. html % make gcc —Wa11 ¯l/usr/local/ssl/include しかし、これだけでは SSL に必要と されるデバッグデータが足りないため、 少々ソースコードに手を入れる。これ は ssl 構造体中に入っているデータの一 部を表示させるだけの簡単な変更であ る ( 図 2 ) 。 変更を行った sslpr 。 xy を再度 make し て、実行してみる。 実行時のパラメータとして、 local host の port 5000 に対して接続を行った 場合、 www.matsui.co.jp の port 443 に対 して接続を行うというものである。 ー 0 —c sslproxy ・ c ー 0 sslproxy. 0 れらのパラメータを与えた上で、プロ グラムをあらかじめ実行しておき、ク ライアントによって接続を試みる。 これにより、暗号化・ハッシュアル ゴリズムならびに接続している SSL 、 TLS のバージョンを表示するようにな っている ( 画面 4 ) 。 gcc ¯wall ¯l/usr/local/ssl/include ー 0 ー 0 sslproxy sslproxy. 0 ¯L/usr/10ca1/ss1/1ib 画面 3 sslproxy を make する 1 . sslproxy のパラメータを設定して実行 —1ss1 % . /sslproxy ー 15000 —Rwww.matsui ・ CO ・ JP ー r443 SSL: No verify locations, trying default proxy ready, listening for connections connection 0 Ⅱ fd=4 SSL : Cert code : 20 in [/C=US/O=RSA Data Security , ation Authority] SSL : negotiated cipher : DES-CBC3¯SHA SSL : cipher version : TLSv1/SSLv3 SSL : negotiated cipher end 2. クライアントとして sslproxy に接続し、 HTML を GET する。 % telnet localhost 5000 Trying 127.0.0.1. Connected to localhost . Escape character iS GET / 工 nc . /OU=Secure Server Certific く tml > く五 e ad> く tit1e>We1come tO Matsui . く /title> く /he ad> く BODY bgcolor="#ffffff"> く CENTER> く H2>P1ease See く A HREF="http://www.matsui. CO ・ jp/">http://www.matsui ・ CO ・ jp/ く /a> く / H2> く / CENTER> く /BODY> く /HTML> Connection closed by foreign hOSt . く ! DOCTYPE HTML PUBLIC " —//W3C//DTD HTML 4.0 Transitiona1//EN"> 画面 4 ss ゆ「 oxy の実行 —lcrypto 2000 NO. 6 BSD magazine 089

インクルードファイルが入っている。 つまり、ディストリビューションの tarball 的にいうと、 sys 、 usr. bin 、 usr. sbin 、 include 、 sh 眠等が必要になる。 これらのファイルはまとめて、 /usr/ local/mipsel-dec-netbsd に放り込んでお /usr/local/mipsel—dec-netbsd f00 % pwd くことにする。こんな感じだ。 f00 % IS b in include 1 土 b f00 % ls usr share SYS こまで解説してきたクロスツール が一式できあがれば、カーネルの構築 を行うことができる。手順は基本的に 普通に pc 用のカーネルを再構築するの と変わらないが、環境変数をいくつか 設定するなど若干の設定が必要にな る。 NetBSD はさすがにたくさんのアーキ テクチャをサポートしているだけあっ て、カーネルの構築環境そのものがク ロス開発を容易にするように設計され ている注 2 。 こでは、 make にかぶせる wrapper カーネルのコンバイル 特集 1 まとめ 発の環境がある注 3 。これをインストー り、実際 NetBSD の pkgsrc にはクロス開 てくる。たしかにそれはその通りであ で作れば楽なのに」という声も聞こえ きそうである。「 NetBSD なら NetBSD 境を作るんだ ? 」という声が聞こえて FreeBSD 上にわざわざ NetBSD 開発環 すでに述べたが、 こで新たな「何で クロス開発環境の必要性については できる。 にして、カーネルの構築を行うことが こまで準備したら、画面 6 のよう あげる必要があるわけだ。 sys. mk などのファイルの所在を教えて を行う場合と異なり、 make コマンドに だ。 NetBSD 上で NetBSD のコンパイル コマンドに渡すオプション回りがそれ なった。具体的にいうと 40 行めの make のであるため、若干の手直しが必要と hpcmps クロス環境としてつくられたも は元々 NetBSD/i386 上での NetBSD/ 修正を入れたものだ。このスクリプト のに筆者が今回の原稿執筆用に若干の ps-make として web から見つけてきたも おこう。このスクリプトは、元々 hpcml としてリスト 1 のスクリプトを紹介して ルすればとにもかくにも一通りの開発 環境はできあがるわけで、わざわざ FreeBSD を使う必要はないようにも思 える。 たしかに、趣味の範疇でいろいろな 開発を行うのであればそうだろう。他 の BSD には目もくれず NetBSD だけを ひたすら追い掛ける姿は見ていてもあ る意味すがすがしい。ところが、仕事 となるとそうとばかりは言ってられな い。 X86 べースの PC のサポートが一番 充実している BSD はというと、 Free BSD ということになるし、ユーザーの 数が多いのもやはり FreeBSD である。 また、何よりクロス開発が簡単にで きるように作られた OS 上でその OS の クロス開発を行ってもまったく普通じ ゃんという趣味人的な考えもあり、 のテーマを選んでみた注 4 。 今回解説したクロス開発環境は、タ ーゲット CPU が違うときだけではなく オペレーティングシステムが違うだけ のときにも有効に応用することができ る。たとえば Solaris 上で FreeBSD の ports コレクションの make を行ったり、 あるいは Gtk や Qt を使って Windows の プログラムを作ることさえ可能と言え るのである。本文を参考にいろいろな クロス開発を楽しんでもらいたい。 % cd $NETBSD-ROOT/sys ; NetBSD カーネルソースのあるところ % cd arch/hpcmips/conf % ${NETBSD—TOOL}/bin/config NULLCONF とりあえずクロス環境の構築が目標なので 一番ー発でコンパイルの通りそうな設定を , 使用 % cd .. /compi1e/NULLCONF % ${NETBSD—TOOL}/make. sh depend % ${NETBSD-TOOL}/make. sh 画面 6 カーネルの構築 注 2 汎用的に仕様とした結果若干設定などが難しくなっている側面があることも否定しないが。 注 3 と言っても若干内容が古いので本格的にクロスで開発するのなら、新しい ( あるいはターゲットにあった ) ソフトウェアをインストールすることをお勧め する。 注 4 筆者が現行の執筆環境に FreeBSD を使っているというのも理由の 1 つではあるが。 2000 No. 6 BS D magazine 029

・鍵共有を含めた安全な暗号通信路の 提供 ・電子証明書と電子署名による本人認 証 ・データ改竄チェック ( データの完全 X. 509 3 証明書発行プロセス 一般的に電子証明書とは、 IETF x. 509 によって定義されたフォーマットに 従ったデータのことを指す。この証明 書を発行するプロセスは、 RSA security 社による規格である PKCS # 10 形式の証 明書要求 (Certficate Signing Request : 以下 CSR) を作成し、 CA に署名をし てもらうのが最も一般的な方法である。 すなわち、図 1 のような手順となる。 これらの作業は、 S/MIME メーラや Web プラウザで鍵ペアと CSR を作成し、 何らかの CA で署名を行った後に、メ ーラやプラウザに証明書を返すといっ た遠隔発行の手法を使うことによって 実現できる。または、 AiCA や Open SSL を使用してすべてのコマンドライ ンで証明を発意した後に、 PKCS#12 形 ( 秘密 + 師 ファイルを S / MIME メーラや web プラウザでインポ ートするといった手法を採ることも可 能である。 AiCA は、名古屋工業大学岩田研究 室により公開された CA アプリケーショ ンであり、 S/MIME や SSLv3 の機能を 備えた暗号ライプラリ AiCrypto 上に実 装されている。ライセンスに関しては 商用、非商用を間わず入手、使用する ことが可能であるが日本国内でのみ利 用することが許されている。これら AiCA 、 AiCrypto は以下の WEB サイト より入手が可能である。 http : //mars . elcom. nitech. ac ・ jp/ security/ なお、 WEB 上での公開に関しては「学 会発表等によりライプラリの要綱がす でに公になっているならば特別な申請 は必要ない」とのコメントを通産省よ りいただいたため行われている。 AiCA のインストール 本文中では表 1 のような環境に合わ せて CA の構築を行っている。 まず最初に、前述のサイトより AiCA をダウンロードする。現在の最新バー ジョンは 0.70.1 である。ダウンロードが 済んだら、ファイルを展開しコンパイ ル・インストールを行う ( 画面 1 ) 。 無事コンパイルが済めば、インスト ール先ディレクトリに bin 、 certs 、 lib 、 include ディレクトリが作成される。な お、 prefix を指定しなければ /usr/local/ aica にインストールを行う。 作成されるファイルの意味 ます、 bin ディレクトリには 7 つのコ マンドが作成されている。これらのコ マンドの用途は表 2 のようになってい る。 ⅱ b 以下には、設定ファイルの aica. cnf が存在するが、このファイルは CA ディ レクトリの指定や、 CSR の作成時に使 用される DN のデフォルト値を指定する 表 1 前提とする環境 % . /configure % make % make install OS ¯prefix=/usr/home/okuno/aica AiCA をインストールしたディレクトリ 画面 1 コンバイル・インストールを行う FreeBSD 3.5-RELEASE /usr/home/okuno/aica /usr/home/okuno/testca 自分の CA のディレクトリ 表 2 コマンドの用途 082 ー BSD magazine a ℃ a asnl View certconv certreq certvfy certview newca. Sh CA 運用に関するコマンド、証明書や CRL の発行等を行う DER 形式のファイルを ASN. 1 タグを使い表示する 証明書、秘密鍵、 PKCS#7 、 PKCS # 12 などのファイルを相互変換する 鍵ペアを生成し、 CSR を作成する 証明書の Verify を行う 証明書、秘密鍵、 PKCS#7 、 PKCS # 12 などのファイルをテキスト表示する 新規 CA の構築 一 2000 No. 6

をコンパイルするのに 48 時間以上かかるようになり、新し これはたとえば夜中に何か問題が起こったときにネット いクラスタの登場が待たれることになった。 ワーク経由で問題を解決することができないということで 3 代目 あるし、 2 代目や 3 代目のクラスタのように筆者が自分で 3 代目のクラスタは Yah 。 0 ! 社の寄付によって作られた。 アクセスすることができない場合にはアクセス権のある人 ご存じの通り Yah 。。 ! 社では FreeBSD を全面的に使ってお 間にメールを送って誰かが直してくれるのを待たないとい り、 FreeBSD プロジェクトのためにといってかなり強力な けないということになる。実際、クラスタの作成直後に電 マシンたちを寄付してくれた。 源スイッチやコンソールがなかったときには非常に困った 2 代目のクラスタと比べて CPU が強力になったのはもち ものである。 ろんだが、一番大きな違いはメモリがべらばうに多いこと クライアントの OS である。そのため、コンパイルを 10 個程度並列に走らせて も基本的にスワップは使わないですむようになっている。 マシンが多数あるときに問題となるのが OS のアップグ 3 代目はサーバー、クライアントとも Yah 。。 ! 標準のラッ レードである。初代と 2 代目のクラスタではクライアント クマント型の pc である。ディスクについてはサーバーの のマシンも普通のディスクつきワークステーションなので、 SCSI ディスクがエンクロージャに入っている以外はすべて マスターで make buildworld をし、クライアントからはマス 内蔵である。このクラスタはカリフォルニア州サンタクラ ターの /usr/src と /usr/obj を NFS マウントして make install ラにある Yahoo ! 社のデータセンターにある。 world をしていた注 5 。 現在 4 , 000 個を越える p 。 rts をコンパイルするのにかかる これには 2 つの問題点がある。 1 つはアップグレードの手 時間は 14 時間ほどとなっている。なお、近いうちにもう少 間で、 NFS ごしの installworld にはかなりの時間がかかり、 しクライアントを増やし、これを何とか 8 時間以内にして クライアント全部をアップグレードするのは半日がかりと 3-stable 、 4-stable 、 5-current のすべての package を一日以内 なる。もう 1 つは何らかの理由で新しいバージョンがちゃ 0 に作れるようにしようともくろんでいる。また、メモリが んと動かないことが判明した場合、元に戻すのが容易でな いことである注 6 。 たくさんあることを生かしてコンパイル用のスクラッチデ イスクを MFS にするなど、さらに高速化を図るための実験 そのため、 3 代目のクラスタではクライアントは OS レス をいろいろとしているところである。 としてマスターのファイルシステムを NFS で使ってプート し、クライアントのディスクはスワップの他コンパイル時 のスクラッチェリアとしてのみ使うことにした。なお、並 列 package 作成システムではコンパイルに使うツール等は この項ではこれらのクラスタを作成・管理するにあたっ chroot 工リア内にあり、これらはローカルディスクのスク ラッチェリアに展開されるのでホスト OS に NFS を使っても て筆者が体験したこと、また一般的に注意すべきことを述 パフォーマンスへの影響はほとんどない。 べてみたい。 ホストの OS と package のターゲットとする OS 電源スイッチとシリアルコンソール リモートでシステム管理をするのにこれらは絶対に欠か FreeBSD の package は 3-stabIe 、 4-stabIe 、 5-current と 3 つ のプランチに対応するものを作っていることはすでに述べ せない。ネットワークから各マシンの電源を切ることので たが、そのときに問題となるのが OS のバージョン依存の きるスイッチがないとマシンがハングするたびにいちいち ソフトウェアである。 chroot 環境ではコンパイラやヘッダ 計算機室に行かないといけない。また、シリアルコンソー ルがないと何か問題が起こったときには計算機室に行って ーファイルなどは当該バージョンのものになっているため、 /usr/include/sys/param. h などを見てインクルードするファイ キーポードとディスプレイをつながないとデバッグができ 注 5 余談であるが筆者が Bruce Evans 氏と協力して FreeBSD の world ターゲットを buildworld と insta Ⅱ w 。 rld に分離したのはこのクラスタのアップグレードを 楽にするためであったことはあまり知られていない。 ; ) 注 6 えてしてこのようなことはアップグレード直後でなく、 package の並列コンパイルのような負荷のかかる仕事をさせてはじめてわかることが多いものだ。 BSD magazine 143 2000 No. 6 ない。 0 クラスタ管理のヒント

作成する c 。 c 。 a アプリケーションはそうした WebObjects で そこで MacOS X では IOK1t というデバイスドライパフレ 開発されている。 ームワークを用意し、 API を整えクラスライプラリをもつ 次期リリースである WebObjects 5 では、 web アプリケー ことの恩恵を継承すると共に、ドライバのアンロードなど ションの動作に必要なライプラリはすべて PureJava 化され、 の機構を追加している。 PureJava のアプリケーションとして WebObjects の Web アプ また、 IOKit での開発は Objective-C ではなく Embedded c + + という、「機能に制限をおいた c + + 」での開発となる。 リケーションを利用できることがアナウンスされている。 もちろん従来の WebObjects でも Java 対応しており、 Java で 制限される " 機能 " とは多重継承などの機能であり、制 の開発をサポートしていたが、ライプラリが Objective-C で 限により c + + の複雑さを回避する一方、 IOKit の提供する 己述されていたため、 WebObjects そのものが移植された環 マクロにより、どちらかというと Objective - c に近い使い勝 境 (Windows NT 、 MacOS X server 、 solaris 、 HP-UX) で 手を実現している。さらに c + + は Objective-C とは違いコン しか動作しなかった。しかし webOb. 」 ects 5 からは、 Java2 さ パイル時にメソッドのバインディングを行うのがデフォル えあればどこでも (Linux でも *BSD でも ) 動くようになる トであるため、実行時の効率も Objective - c に比べて良好 のだ。 である。 残念ながらまだ Apple は MacOS x 上で動作する web Objects を公表していないが、これまでの経緯と J 。 bs の Java2 に関する発言を考えると WebObjects の主要な開発 / 運 用環境の 1 っとして MacOS x が使われることは間違いな 一三ロ 実際の開発 では、実際の開発がどうであるかをみていくために BSD 環境にて伝統的な hell 。 . c の開発と、そして MacOS x のもっとも中心的な開発環境である c 。 c 。 a 環境にて GUI ア プリケーションの開発を実際に行ってみる。 IOKit Embeded C + + これまでは主にアプリケーションの開発についての環境 であったが、もちろんアプリケーション以外にも開発すべ BSD での開発の実例 : hello. c きソフトウェアは存在する。その中でも大きいものとして ますはウォーミングアップに、 BSD 環境での開発を試し に行ってみる。 デバイスドライバがあげられる。 MacOS でのデバイスドライバの開発は混迷を究めてお TerminaI を起動すれば、そこはみなれたコマンドライン り、たとえば USB では、機器接続時に動的にドライバを口 の世界である。 ードし、ドライバがなければネットワークからダウンロー いつものようにⅵを起動注 7 してリスト 1 にあるソースコ ドを試みるという優れた機構を持ち合わせている一方、 ードを hello. c というファイル名で作成し、以下のコマンド 般的には OS によるまともなプロテクション機構がないため を Termina1 から実行する。 に低レベルルーチンにまで介入してくるアプリケーション におびえつつのプログラミングを余儀無くされている。 > cc ー 0 he110 he110. c NeXTSTEP では DriverKit というオプジェクト指向の優れ たデバイスドライバの開発環境があり、「各ドライバの親 クラスからサプクラスを作って、初期化などの最低限のメ ソッドを実装するだけ」という非常に効率的な開発手法が 取られていたが、これは実装に Objective - c という言語を用 いていたため効率の面に問題があり、また仕様上の問題で ドライバのアンロードができないという弱点も抱えていた。 マリスト 1 hello. c #include く stdio . h> char *argv ロ ) int main( int argc , (again) *n" ) ; printf ( " he110. 注 5 WebObjects の残りのサポート環境である solaris 、 HP - UX では残念ながら Applica ⅱ。 nK1t が提供されていない注 6 ため、 GUI をもったアプリケーションは 開発できない。 注 6 sun はかって、 NeXT と共同で SolarisOPENSTEP という solaris の上で動く OpenStep 環境を構築しており、このときに ApplicationKit を自社の DPS を搭載 した x の上に移植したはずである。 sun は Java への傾倒とともに s 。 IarisOPENSTEP を自ら封印してしまったのだが、なんとも惜しい話である。 注 7 人によっては Emacs ( 標準で 20.7.1 というバージョンのものが付属している ) かもしれないが、普通、ⅵですよね ? : - ) 110 BSD magazine 2000 NO. 6

実装の詳細 注 8 または涙ぐましい。 れているデータにアクセスしてはいけ splhigh() 以下のレベルによって保護さ ているコードは tty に関連するデータや だし、 IPL_SERIAL のレベルで動作し を取りこばしたくないからである。た されている間にシリアルからのデータ たくさんある。この理由は、 splhigh() 位が高くなっているアーキテクチャが IPL-SERIAL のほうが割り込み優先順 HIGH より、 splserial() のレベルである とえば splhigh() のレベルである IPL レベルを新たに作ることもできる。た ができ、 splhigh() よりも高い割り込み 管理メカニズムを自由に設計すること クチャによっては、割り込みレベルの 意図したものである。しかしアーキテ 本来、 splhigh() は割り込み全禁止を sp 旧 igh0 と N 、 WAN の割り込みレベル ア割り込みを使用している。 はしない。 NetBSD/sh3 でもソフトウェ 込みはすべて受け付けないという動作 し、現在の割り込みレベル以下の割り ウェア割り込みと呼ばれる方式を採用 にはアーキテクチャによってはソフト 昔から同じ名前を使っているが、実際 を行っている。インターフェイス名は level) べースの割り込み優先順位管理 NetBSD は伝統的な spl (set priority 割り込み応答性の向上 れる点まで並べてみた。 がつきにくい細かな点から重要と思わ るが、普通の NetBSD の使い方では気 的に紹介する。つまらない注 8 変更もあ 程で遭遇した問題とその解決法を具体 SEIL T 1 のファームウェアの実装過 ない ( たとえば mbuf のアロケーショ ン ) 。 SEIL TI では、 LAN と WAN の割り込 み応答性を上げるため、 IPL_SERIAL よりさらに高い割り込み優先順位とし て、それぞれ IPL_ETHER 、 IPL_PRI MAL を用意している ( リスト 1 ) 。各割 り込みルーチンはこのレベルで動作し、 ごく低遅延で実行しなければならない デバイスとのやりとりだけを行い、最 後にハードウェア割り込みとは別に用 意されたソフトウェア割り込みを発生 させて終了する。すぐ終わる高い順位 の割り込み処理がひととおり終わると、 低い順位で仕掛けたソフトウェア割り 込み用の割り込みルーチンが呼ばれ、 残りの作業を行うことで本来やるべき 作業をすべて終える。 SEILTI ではこのように割り込みレベ ルを巧みに使い分けることで割り込み 応答性能を上げている。 ウォッチドッグタイマと割り込み応答性 SH3 はウォッチドッグタイマを内蔵 マリスト 1 割り込み優先順位の定義 (include/intr. h) / * lnterrupt priority 、 levels し * / しており、 NetBSD/sh3 にはこのデバイ スのデバイスドライバがある。 SEIL TI でもこのドライバを使っている。 本来ウォッチドッグタイマは、シス テムがハングアップしたことを検知し てシステム全体をリセットするための ものである。ところが、 SH3 のウォッ チドッグタイマはカウンタのクロック が高いうえにカウンタのビット幅が 8bit しかないため、長めに splhigh() でプロ ックするとすぐにリセットが発生して しまう。 SEILTI のハードウェア構成で は、ウォッチドッグタイマの待ち時間 の最大長は 30ms 強となっている。 SEILTI の開発時にはこれを逆手に 取り、ウォッチドッグタイマをリセッ ト発生のモードではなく割り込み発生 のモードに設定することで、高い割り 込み禁止レベルで動き続けた場合にウ ォッチドッグタイマから割り込みがか かるようにして開発している。これを 用いて、実際にシリアル ( コンソール ) のデバイスドライバが不用意に割り込 み禁止レベルを上げてシステムのスム #define #def ine #def ine #define #define #define #define #define #define #define #de f ine #de f ine #define #define #define #define #def ine IPL_NONE IPL_PRIMAL IPL_ETHER IPL_SERI AL IPL—HIGH IPL_CLOCK IPL_AUDIO IPL_SOFTSERIAL I PL_S OFTNET IPL_ S OFTCLOCK NIPL IPL_IMP IPL—TTY I PL_NET IPL_BIO splprimal ( ) splether ( ) 11 10 9 8 7 6 5 5 4 3 3 2 1 0 12 / * nothing * / timeouts * / / * p て 0t0C01 stacks * / / * block I/O * / network * / terminal * / / * memory allocation * / / * audio * / / * clock * / / * everything * / / * serial * / ethernet device * / / * primal device * / splraise (imask [IPL—ETHER] ) splraise (imask [IPL—PRIMAL] ) 2000 No. 6 BSD magazine 037