Posts

OpenBSD Problem Reports

https://www.openbsd.org/report.htmlの OpenBSD Problem Reportsを読んだので、訳を試みておく。 OpenBSDの問題の報告リリース済みのバージョンに関する問題の報告 リリース済みのバージョンについて、バグや問題を報告する前には、以下のチェックリストを確認してください。 まず、このリリースについてのパッチと正誤表を確認してください。次に、より新しいバージョンさリリースされていないか確認してください。最後に、各バージョン間の変更履歴を確認してください。 もしどれにもあなたの問題が含まれていなかった場合には、バグを報告する前にsendbug(1)コマンドについて学んでください。 currentの問題の報告 -releaseでも-stableでもなく、-currentのソースツリーにあなたの問題がある場合には、以下を確認してください。 少なくとも2回、その問題をテストしてください。その時のソースコードは数日離れたものにしてください。ソースツリーがコンパイルできないという問題は、それが長く続くのでなければ報告しないでください。この種の問題はあなたのミスであるか、作業中のソースツリーを利用してしまっていることがほとんどです。プロジェクトで働いている人は、少なくとも1日に1回はmake buildを実行しています。普通は異なるアーキテクチャーで1日に等も実行しています。AnonCVSサーバーは、実際の作業中のソースツリーが反映されるのに数時間かかることを覚えておいてください。各バージョン間の変更履歴に既に掲載されていないか確認してください。スナップショットを作る際には、十分に注意していますが、時にはミスをすることもあります。その場合は謝罪します。バグ報告を送るより、メーリングリストで話をする方が適切です。問題報告 常にできる限り多くの情報を提供するようにしてください。問題をピンポイントに絞り込むようにしてください。問題を再現できる明確な手順を教えてください。なるべく正確で混乱を生まないよ言葉を使うようにしてください。このことは、特に再現の難しい問題の場合には重要です。問題を説明するのに「クラッシュする」や「私の組み立てたマシンで奇妙な割り込みの問題が起きた」といった文は役に立ちません。 (メーリングリストやその他の知…

「リーダブルコード」より、「コードの欠陥にコメントをつける」

リーダブルコードを読んでいて、以下の表は覚えておきたいと思ったので抜粋しておく。 記法典型的な意味TODO:あとで手をつけるFIXME:既知の不具合があるコードHACK:あまりキレイじゃない解決策XXX:危険! 大きな問題がある TODO:は大きな問題に使って、小さな問題にはtodo:やmaybe-later:を使うという場合もあるかもしれない

HelenOSのよくある質問と答え

HelenOSについて興味があるのだが、日本語の情報がない。 FAQを読んでみたので記載しておく。 2019年1月18日時点のhttp://www.helenos.org/wiki/FAQの内容である。 基礎的な概念マイクロカーネルとは何か? マイクロカーネルオペレーティングシステムでは、 デバイスドライバーやファイルシステム、ネットワーキングなどの機能は、 カーネルスペースからユーザースペースへと追い出されている。 カーネルの外のコードは、通常のユーザープロセスとして実行される。 マイクロカーネル自体は、ユーザープロセスが実行と通信できる最低限の機能のみを提供する。 これは、伝統的なモノリシックなオペレーティングシステムが、これらのほとんどを カーネル内部に持っているのと対照的である。 マイクロカーネル設計に従ってオペレーティングシステムを構築する根拠は、 オペレーティングシステムのポリシーのほとんどをユーザースペースへと追い出し、 マイクロカーネル自体を可能な限りポリシーから自由にし、より大きな 拡張性を実現することである。 このことにより、マイクロカーネルは異なるオペレーティングシステムとしての性格を 提供することもできる。 これは同時に複数の性格を1つのマイクロカーネルの上に構築することさえ論理的には可能とする。 これにより、オペレーティングシステムカーネルに機能をハードコードするのではなく、 簡単に機能を変更できるようになる。 マルチサーバーマイクロカーネルにより、限定的なフォールトトレラントな利用も可能となる。 モノリシックなオペレーティングシステムのカーネルドライバーにバグがあった場合、 通常はシステム全体がクラッシュする。 しかし、マイクロカーネルオペレーティングシステムのユーザースペースドライバーにバグがあっても、」 ドライバーを実行するユーザープロセスがシステム全体をクラッシュさせることはない。 マルチサーバーとは何か? マイクロカーネルオペレーティングシステムの視野の範囲内では、 マルチサーバーは、複数のユーザープロセスにまたがってオペレーティングシステムの機能が 広がっていることを指す。 これは、全ての機能が1つのユーザープロセスに集約されているシングルサーバーマイクロカーネル とは異なる。 システムをマルチサーバーにしようという動機は、…

RISC OSがApache License Version 2.0になったので

RISC OSがApache License 2.0で公開される と言うニュースを見ていたのだが、具体的にどういう風に変更されたのか把握していなかった。 RISC OSのソースコードはCVSで管理されているのだが、 castleというディレクトリー がapacheというディレクトリーに改名されて、 LICENSEというファイルでApache License Version 2.0が 置かれるようになった。各ソースファイルにもApache License Version 2.0の 適用される旨のヘッダーが含まれるようになったのだが、 どうやらそれはCVSのリポジトリーを直接編集したように見える。

NetBSD/amd64-currentをAmazon Web Service EC2 c5インスタンスで動かしてみる

Image
この記事は、 NetBSD Advent Calendar 2018の23日目の記事です。 はじめに もう1年以上前の話だと思うのですが、Amazon Web Service (AWS) EC2にc5という Linux KVMをAmazonが独自拡張したと言うインスタンスのタイプが追加されました。 その後、同じような仕組みのm5インスタンスと言うもの追加されているようです。 c5インスタンスでは、Elastic Network Adapter (ENA)と言うEthernetアダプター を利用できることが必須になっているようです。 NetBSD/aarch64では、a1インスタンスでena(4)がFreeBSDから移植されていて 無事に動いていますが、 c5インスタンスでのNetBSD/amd64の動作確認結果は聞いたことはありませんでした。 そもそもc5インスタンスで起動できるAMIの作り方も良く分かりませんでした。 今回は、カーネルパニックでena(4)は動かせるまで至りませんでしたが、 c5インスタンス用のAMIの作成をまとめておくことは意味があるかもしれません。 AMIファイルの作り方を調べてみる AWS EC2のAMIは、直接ダウンロードしてみることはできないようです。 裏にはスナップショットと言うものがあるようですが、Amazonが公開している Amazon LinuxのAMI用のスナップショットを見ることはできないようです。 今回は、FreeBSD/amd64 12のAMIからc5インスタンスを作成し、そのディスクの 構造を見てみました。それを見ると、NetBSDで言うと、GPTパーティションからの BIOSブート(UEFIブートではない)であることが分かりました。 かつて、UEFIブートができないことにGPTを使っていたやり方を思い出せば良さそうです。 ここで、カーネルは、 ena* at pci? dev ? function ? # Amazon Elastic Network Adapter の行をGENERIC設定ファイルに追加した追加したGENERIC_ENA設定ファイルでビルドします。 ; 3GBのディスクイメージファイルを作成します $ dd if=/dev/zero of=./netbsd-c5-…

NetBSD/amd64でChisel HDLからVerilogを生成してシミュレーションしてみる

この記事は、 NetBSD Advent Calendar 2018の20日目の記事です。 はじめにMIPSの 命令セットアーキテクチャーと実装が オープンソースになるような時代が来るとは思っていませんでした。 これもRISC-Vへの期待に影響があるのかもしれません。 Chiselと言うハードウェア記述言語は、そのRISC-Vの代表的な実装である Rocket chip の多くの部分を書くのに使われているものです。 今回は、Rocket chipは大規模過ぎるので、Chiselのチュートリアルである Chisel TutorialsのChiselコードをVerilogに変換して、 verilatorでのシミュレーション実行もしてみたいと思います。 私はこれからChiselで書いてみたい回路があるのですが、 NetBSDで生活して良くあるのは、そもそも環境が整わない、整ったと思ったら誤作動している と行ったことなので、既存の正しく動くことの分かっているものが、同じように動くことを 確認するのは大切です。 Chiselの環境の準備 Chiselは、ScalaというJava Virtual Machine (JVM)で動く処理系で書かれています。 Chisel自体が、Scala言語のドメイン固有言語(DSL)になっています。 Chiselの処理系は、sbt (pkgsrc/lang/scala-sbt)を使って各環境ごとに それぞれ用意します。 ですので、/usr/local以下にインストールしておくといったことは 一般的ではないようです。 まずは、pkgsrc.lang/scala-sbtのインストールですが、 NetBSD/amd64のネイティブなOpenJDK 8ではうまく動きません。 Java Native Access (JNA)がサポートされていないのが いけませんし、他にも理由はありそうです。 pkgsrc/lang/openjdk8をちゃんと直さないといけません…。 ですが、ここでは先を急いでpkgsrc/lang/oracle-jdk8を 使うことにしてしまいます。 java.sun.com からLinux/x86_64用のJREとJDKの配布物をダウンロードして$DISTDIR に配置した上で、以下のように実行すれば良いでしょう。 #…

NetBSD/amd64-current上でIntel Quick Sync Videoを使ってみる

この記事は、 NetBSD Advent Calendar 2018の10日目の記事です。 はじめに IntelのCPUに内蔵されているGPUには、Intel Quick Sync Video (QSV)というビデオのデコードとエンコードをする仕組みが入っています。 今回は、KabylakeなIntel Core i7なチップの搭載されているHP Spectre x360 ae019TUで、NetBSD/amd64 8.99.27上で、 H.264のビデオのデコードとエンコードをQSVでさせてみました。 エンコードには、pkgsrc/multimedia/ffmpeg4を使い、 デコードには、pkgsrc/multimedia/mpvを使います。 比較のためにfmpeg4でCPUを使ってH.264を利用しますが、 これには本来はライセンスが必要なはずです。 CPUを使ってH.264のデコード/エンコードをしてはいけないと思います。 Intel QSVを使用する準備 NetBSDでIntel QSVを使うためには、pkgsrc/multimedia/libva (VA API)を使うのが一番良いようです。 Intel Media SDKはもしNetBSDで使えたとしても相当苦労するのが明らかですし、 VDPAUは、2015年以降のコミットは2018年11月の2件のみです。 NetBSD/amd64 8.99.27で必要なものをpkgsrcからインストールします。 pkgsrc/multimedia/ffmpeg4も pkgsrc/multimedia/mpvもNetBSD/amd64 8.99.27ではpkgsrc/multimedia/libva に依存するのが既定値になっています。 本当に自分の環境でlibvaサポートが有効になるかを確認したい場合にが、 make show-optionsの出力にvaapiが含まれているかを確認すれば良いでしょう。 libvaからIntel QSVを使うには、pkgsrc/multimedia/intel-vaapi-driverが必要です。 また、libvaの動作確認をするには、pkgsrc/multimedia/libva-utilsがあると良いです。 # cd /usr/pkgsrc/multimedia/ffmp…