OmniOS-discussメイリングリストのThe Future of OmniOSと題された投稿 によると、OpenSolarisの流れを組むOmniOSについて、開発元のOmniTI社は開発から手を引くことにしたようだ。
個人的には、OpenSolaris/illumosベースのOSを使いたい時には、OmniOSを使って来たので残念だ。 会社としてではなく開発者たちは継続して開発に参加するし、今後はコミュニティーで開発が継続されることを望んでいるようなので、 すぐになくなってしまう訳ではないかもしれない。 しかし、開発の活発さは失われてしまうのかもしれないと思っている。
VAIO S13を使う機会があってNetBSD/amd64-currentを動かしてみたが、 ACアダプターについても書いておく。 附属のACアダプターは、Vaio Pro 11やVaio Pro 13、Vaio Pro 13 mk2、Vaio Pro 13 mk3と同様な VJ8AC10V9だった。10.5V 3.8Aと、5.0V 1.0AなUSB電源の 組み合わせである。 であるから、過去の記事と同様に、サードパーティーのACアダプターを使用できた。
ほんのちょっとの期間ではあるが、Vaio S13を使う機会があったので、NetBSD/amd64 7.99.70を起動させてdmesgを取得してみたので、書いておく。
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 7.99.70 (GENERIC) #0: Wed Apr 26 11:38:37 UTC 2017
mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC
total memory = 3894 MB
avail memory = 3759 MB
cpu_rng: RDSEED
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
running cgd selftest aes-xts-256 aes-xts-512 done
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
VAIO Corporation VJS131 (Reserved)
mainbus0 (root)
ACPI: RSDP 0x00000000000F0120 000024 (v02 VAIO )
ACPI: XSDT 0x00000000B7FD2188 0000DC (v01 Sony VAIO 20161014 PTEC 00000002)
ACPI: FACP 0x00000000B7FF0000 0000F4 (v05 Sony VAIO 20161014 PTEC 00000002)
ACPI: DSDT 0x00000000B7FDB000 010598 (v02 VAIO VAIO 20161014 INTL 20141107)
ACPI: FACS 0x00000000B7F65000 000040
ACPI: TCPA 0x00000000B7FFB000 000032 (v02 VAIO VAIO 20161014 PTEC 00000002)
ACPI: SLIC 0x00000000B7FFA000 000176 (v01 Sony VAIO 20161014 PTEC 00000002)
ACPI: SSDT 0x00000000B7FF9000 0004C5 (v02 VAIO VAIO 20161014 INTL 20141107)
ACPI: SSDT 0x00000000B7FF8000 00004B (v02 VAIO VAIO 20161014 INTL 20141107)
ACPI: TPM2 0x00000000B7FF7000 000034 (v03 VAIO VAIO 20161014 PTEC 00000002)
ACPI: UEFI 0x00000000B7F7B000 000042 (v01 VAIO VAIO 20161014 PTEC 00000002)
ACPI: SSDT 0x00000000B7FF1000 0052DE (v02 VAIO VAIO 20161014 INTL 20141107)
ACPI: HPET 0x00000000B7FEF000 000038 (v01 VAIO VAIO 20161014 PTEC 00000002)
ACPI: LPIT 0x00000000B7FEE000 000094 (v01 VAIO VAIO 20161014 PTEC 00000002)
ACPI: APIC 0x00000000B7FED000 0000BC (v03 VAIO VAIO 20161014 PTEC 00000002)
ACPI: MCFG 0x00000000B7FEC000 00003C (v01 VAIO VAIO 20161014 PTEC 00000002)
ACPI: SSDT 0x00000000B7FDA000 0002D4 (v01 VAIO VAIO 20161014 INTL 20141107)
ACPI: DBGP 0x00000000B7FD9000 000034 (v01 VAIO VAIO 20161014 PTEC 00000002)
ACPI: DBG2 0x00000000B7FD8000 000054 (v00 VAIO VAIO 20161014 PTEC 00000002)
ACPI: BOOT 0x00000000B7FD7000 000028 (v01 VAIO VAIO 20161014 PTEC 00000002)
ACPI: BATB 0x00000000B7FD6000 000046 (v01 VAIO VAIO 20161014 PTEC 00000002)
ACPI: SSDT 0x00000000B7FD5000 000E73 (v02 VAIO VAIO 20161014 INTL 20141107)
ACPI: MSDM 0x00000000B7FD4000 000055 (v03 VAIO VAIO 20161014 PTEC 00000002)
ACPI: FPDT 0x00000000B7FD3000 000044 (v01 VAIO VAIO 20161014 PTEC 00000002)
ACPI: UEFI 0x00000000B7F62000 0001A2 (v01 VAIO VAIO 20161014 PTEC 00000002)
ACPI: SSDT 0x00000000B7FD0000 001450 (v01 VAIO VAIO 20161014 INTL 20141107)
ACPI: BGRT 0x00000000B7FFC000 000038 (v01 VAIO VAIO 20161014 PTEC 00000002)
ACPI: Executed 3 blocks of module-level executable AML code
ACPI: Executed 1 blocks of module-level executable AML code
ACPI: 7 ACPI AML tables successfully acquired and loaded
ioapic0 at mainbus0 apid 2: pa 0xfec00000, version 0x20, 120 pins
cpu0 at mainbus0 apid 0
cpu0: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, id 0x406e3
cpu1 at mainbus0 apid 2
cpu1: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, id 0x406e3
cpu2 at mainbus0 apid 1
cpu2: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, id 0x406e3
cpu3 at mainbus0 apid 3
cpu3: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, id 0x406e3
acpi0 at mainbus0: Intel ACPICA 20170119
acpi0: X/RSDT: OemId < Sony, VAIO,20161014>, AslId
2017年4月11日に OpenBSD 6.1がリリースされていた。
6.0からの変更点のうち、気になったものは以下の通り。
DragonFly BSD 4.6.2が2017年4月4日にリリースされていた。
4.6.1からの変更点の内、気になったものは以下の通り。
またパッチを投稿したくなったので、最新版を訳しておく。NetBSDサポートも取り込んでもらえるようなので。
http://wiki.qemu-project.org/Contribute/SubmitAPatch
Edition: 12:49, 31 March 2017 Huth Licensed under GNU Free Documentation License 1.2.
QEMUは(バグの修正であれ新しい機能の追加であれ)コードの貢献を歓迎しています。 しかし、私たちはたくさんのパッチを受け取っており、パッチを提出するためのガイドラインを用意しています。 これらに従うことによって、私たちのコードレビューを容易にし、より早くあなたのパッチがコミットされることになります。
このページは非常に長いと思われるかもしれません。 あなたが簡単なパッチを一回だけ送りたいだけであれば、 最低限の要求は以下の通りです。
git commit -sまたはgit format-patch -sで追加できます。
git send-emailを使えば、パッチを壊すことなく配送することができますので、これが最良の方法です(設定のヒント)。
パッチの電子メールへの添付は初回のパッチの提出でどうしようもない時にのみ使うことができます。
メーリングリストにポストするのに、購読する必要はありません(メーリングリストのポリシーとして、CCを全て保持し、購読していない人が始めたスレッドに入り続けられるように、全員に返信することになっています)。 購読するならば、配信されてくる電子メールが非常に多いのを覚悟してください。一週間に100通を越えることがよくあります。 メーリングリストはモデレートされています。ある電子メールアドレスからの最初のポストは(購読しているにしろ、していないにしろ)、モデレーターがあなたの電子メールアドレスをホワイトリストに追加するまでしばらく時間がかかります。
大規模な貢献や継続的に貢献を続けるつもりであれば、このページの残りの部分も重要になります。 目次を読むことで、基本的な要求事項の概念を把握することができます。 目次をレファレンスとして使用しつつ、疑問がある部分を読んでください。
ここに目次が入る(この日本語訳では省略)
私たちのコーディングスタイルに従っているか確認するために、提出する前に、「scripts/checkpatch.pl <パッチファイル>」を実行してください。 特にCプリプロセッサーが絡む場合には、checkpatch.plが絶対正しいと言うことはありません。常識も使ってください。
以下も参照してください。
QEMUのリリースバージョンに対してのパッチを提出することに意味はありません。開発は進んでおり、そのパッチがmasterに適用できるとは限らないからです。 私たちは、選ばれたバグ修正のみをリリースブランチに適用しており、masterに取り入れられたコードのみをバックポートしています。
長いパッチは、論理的に正しいコードの変更からなるパッチ連続として分割してください。 それぞれの変更は、コンパイルでき、実行できなくてはなりません。 例えば、1つ目のパッチでMakefileにファイルを追加し、2つ目のパッチでそのファイル自体を追加すると言った形式は認められません(このルールは、後ほどgit bisectのようなツールを使う場合に、あるバグを追っている時に、そのバグ以外の問題でQEMUが動かないと言うことがないようにするためです)。 文書は最初にしてください。最後にしてはいけません。と言うのは、誰かが一連のパッチを読む際に、文書をクリーンルームで評価し、コードと文書が一致しているかを確認することができるようにするためです。 コミットメッセージで「Also, ...」と書かれているのであれば、複数のパッチに分割できると考えてください。 適切に分割されたパッチと、良いコミットメッセージを書くことについてのアドバイスとしては、OpenStackのアドバイスを参照してください。
一連のパッチが大規模なコードの移動を必要とする場合には、そのリファクタリングのレビューを簡単にするコツがあります。 意味が変わる変更(あるいは、関数の名称変更も)は、本来の別の一つのパッチにし、コードの移動の部分とは分けておきます。 一時的に、git config diff.renames true; git config diff.algorithm patienceを使ってください。 「diff.renames」プロパティーにより、ファイル名変更のパッチは、古いファイルを削除して新しいファイルを追加するのではなく、ファイル名変更に特化したコンパクトな表現になります。 また、「diff.algorithm」プロパティーにより、元のファイルの}の行を別の変更された塊であるとして扱うことにより、連続しない一部分を古いファイルから新しいファイルに移す際に分かりにくさを低減させることができます。
コードの移動のパッチは以下のようにしてレビューに回されるのが理想的です。
git format-patch --stdout -1 > patch; diff -u <(sed -n 's/^-//p' patch) <(sed -n 's/^\+//p' patch)これにより、大規模なコードの移動ではない一部の変更に着目することができます。
特に伝えておきたいこととして、体裁を整えたり、コーディングスタイルを変更したり、ホワイトスペースの変更を、パッチが変更しないコードについて変更しないでください(あなたの変更しているコードのコーディングスタイルの問題を数行修正するのは問題ありません)。 もし、ある程度の大きさ部分のコードが本当に字下げを変更されたり、大規模なスタイルの修正されたりする必要があるのであれば、意味の変更のない変更として、別のパッチの形で提出してください。
QEMUのあまり変更されない部分についての小さなパッチは、重要ではないパッチのためのプロセスを使うことを検討してください。
コミットメッセージは意味があるように書かれるべきであり、歴史的な記録として、なぜどのあなたの変更が必要であるか、あるいは、有用かを明示するようにしてください。
QEMUは、一般的なgitのコミットメッセージの標準に従っています。つまり、1行目(これは、電子メールの件名になります)は、「サブシステム: 変更の1行でのまとめ」とします。
「変更の1行でのまとめ」は、大文字で始め、再度には「.(ピリオド)」を付けません。
git shortlog 30を見て、例として件名はどのようになっているか確認してください。
2行目は空行です。3行目からはパッチの詳細についての説明を記載し、空行を挟んで、Signed-off-by:の行を記載します。
コミットメッセージは1行当たり76文字以上にはしないでください。
(git showを80文字幅の端末ウィンドウで表示させたときに
表示が乱れないようにするためです。)
コミットメッセージの本文には、あなたの変更が重要である理由を記載してください。 コメントには、「これはこのバグを修正するものである」に類することは書かないでください(こういう内容は、電子メールの「---」の行以下に記載してください。その部分は最終的なコミットメッセージには含まれません)。 コミットメッセージの本文は、読む人の電子メールクライアントが件名を離して表示させたとしても分かるように、独立した文章にしてください(つまり、「... so that」のように件名から文章が続いているのはいけません)。
パッチはTo:メーリングリストとCC:あなたの修正したファイルのメンテナーで送ってください。 MAINTAINERSファイルで、誰がメンテナーを確認できます。 また、scripts/get_maintainer.plを使うことで、あなたの修正したファイルを最も良く変更しているコミッターが分かります。
例えば、
~/src/qemu/scripts/get_maintainer.pl -f hw/ide/core.c
実際には、この作業は自動化できます。
git config sendemail.cccmd 'scripts/get_maintainer.pl --nogit-fallback'
のように初回にセットアップしてください。
パッチは本文中に記載し、レビューコメントを返信しやすいようにしてください。添付ファイルとして送ってはいけません。
正しい差分の形式を使ってください。 git format-patchは、正しい形式のパッチを含んだ電子メールを生成します(どのように動くのか文書を確認してください)。 git send-emailでメーリングリストに送る前にカバーレターを変更することができます。 (私たちはgit send-emailを使うことを勧めています。なぜかと言うと、電子メールクライアントは、長い行を折り返したり、空白を削除したりすることがあるからです。 ディストリビューションによっては、send-emailをデフォルトではインストールしていないことがあります。追加でダウンロードしなくてはいけない場合があります。例えば、Fedoraベースのシステムでは、git-emailをインストールします) 一連のパッチにはカバーレターが必要です。カバーレターは、スレッドの浅い部分になくてはなりません(全ての一連のパッチは、カバーレターへの返信であり、パッチ間の返信であってはなりません)。一つの独立したパッチは、カバーレターを必要としません(あえてカバーレターを使う場合には、--numberedを使い、カバーレターとパッチを件名で見分けられるようにしてください)。 パッチは見付けやすいように新しくトップレベルのスレッドで送信してください。他の既存のスレッドに返信して、埋もれさせてはいけません。
詳しくは、SubmittingPatch 1.12を参照してください。 これは必須であって、これがなければあなたのパッチを受け入れることはできません。 別名や頭文字ではなく、本名を使うようにしてください。
あなたがパッチを書きたら、From:行とSigned-Off-by:行は同じ綴りを使ってください。 メーリングリストに投稿したり、貢献するのに複数の電子メールアドレスを 使うのは問題ありませんが、複数のアドレスを1つのコミットに含めるのは 混乱を生じさせます。 もし、ほかの人が書いたパッチであれは、gitはFrom:行を電子メールの本文に 含めます(あなたのenvelope From:とは異なります)。 これにより正しい作者のクレジットを含めることはできます。 しかし、繰り返しになりますが、作者のSigned-Off-by:行は必須であり、 綴りは一緒でなくてはなりません。
これは通常、複数のパッチを一連のものとして貢献する場合に当てはまります。 カバーレターは一連のパッチの全体としてのゴールを説明するものです。
レビュアーはレビューを始めた段階ではあなたのゴールを分かっていません。まだ文脈を十分に共有していないのです。一連のパッチの最後を見るまで、意味のある変更であると理解できないかもしれません。 ゴールが不明確である一覧のパッチは、レビュアーが十分に考えられないため、レビューと修正のサイクルの数を増加させる恐れがあります。 カバーレターがレビュアーにこれらのポイントを説明できれば、プロセスはスムースになり、パッチはより早くマージされます。 カバーレターには一連のパッチを通じてのdiffstatsを含めることで、レビューしようとする人が関心のあるファイルについて知ることができるようにしてください。 あなたの一連のパッチが関心のあるファイルを変更しているかを知る簡単な方法が求められています。
例えば、「[PATCH RFC v2]」のようにします。 git format-patch --subject-prefix=RFCが便利です。
「RFC」は、「Request For Comments(コメントを希望)」を意味し、あなたのパッチがmasterにそのまま適用されることを意図していないが、レビューして欲しいと言うことを示しています。
このようなことをする理由には以下のようなものがあります:
この場合、一般的に、レビューされた内容はそのままコミットされないので、以下のようであるのが最良です:
全てのQEMUプロジェクトに提出されたパッチは、受け入れられる前に必ずレビューのプロセスを通過します。 良くメンテナンスされている分野のコードは、速やかにレビューされますが、あまりメンテナンスされていない分野では遅れがちです。
そのままでQEMUに取り込まれるパッチは多くはありません。開発者がバグを発見したり、より明確なアプローチを示唆されたり、コードスタイルの問題を指摘されたり、コミットメッセージの誤字脱字を指摘されると言ったとこてぁ、極めてよくあることです。 あなたは、このような指摘に応える必要があります。そして、問題を修正した第2版のパッチを送る必要があります。 これは、あなたの側の時間と苦労を伴いますが、これをしなくては、QEMUにあなたの変更が取り込まれることは決してありません。 これは、礼儀正しくあるということでもあります。あなたのコードをレビューし、改善を示唆するのに時間を費した開発者は、あなたがそれ以上に何かをしないのであれば、時間を浪費したと言うことになり、たいへんがっかりさせられます。
あなたのパッチへのコメントに返信する際には、全員に返信し送信者のみに返信しないようにしてください。全ての議論をメーリングリストに残しておくことで、全員がその内容を参照することができます。
誰かがその時間をあなたのコードを。レビューするのに使ってくれたのです。その努力には敬意を払うべきです。以前にもらったレビューの内容を反映させることなく一連のパッチを投稿し続けることは、レビュアーを遠退かせ、あなたのパッチが行き詰まることを意味します。 レビュアーは常に完璧であるとは限りません。ですので、レビュアーによる要求を全て盲目的に受け入れるのではなく、あなたのコードが正しいと主張することができます。 一方で、誰かがレビューの過程であなたのコードに潜んでいる問題を指摘したが、結局あなたのコードが正しかったとします。そのような場合には、コミットメッセージや。コメントを修正し、なぜあなたのコードが正しいか説明するようにしてください。
もしレビューの過程で浮かび上がった問題を修正したら、それを修正した1つのパッチを投稿するのではなく、一連の全てのパッチを再送信するようにしてください。 これによりメンテナーは手動でどのパッチが適切であるかを判別することなく、簡単に修正された一連のパッチを適用させることができます。 新しいバージョンは完全に新しい電子メールあるいは一連の電子メールで送ってください。バージョン1に返信しようとするのは止めてください(こうすることにより、自動化されたパッチ電子メール取り扱いツールがv1とv2の電子メールを判別できるのを助けます)。
最初のバージョン以外の全てのパッチはバージョンタグを含む必要があります。例えば、「[PATCH v2]」のようにします。 これにより、誰もが最新バージョンを簡単に見分けることができるようになります。 (最初のバージョンは「v1」を付ける必要はありません。「[PATCH]」で十分です。) 一連のパッチにおいては、バージョンは一連のパッチの全てに付加される必要があります。一つのパッチのみが変更されたとしても、全てのパッチに「v2」を付加して再送信する必要があります。 1つの一連のパッチで違ったバージョンを付けようとしないでください。 git format-patchとgit send-emailのいずれも-v2オプションを使うことで、これらを簡単に実施することができます。 新しいバージョンをそれぞれ新しいトップレベルのスレッドとして送信してください。以前のバージョンに返信して、埋もれさせてはいけません。多くのレビュアーがスレッドに深く潜らないと新しいパッチを見付けられないようではいけません。
第2版以降のパッチには、以前のバージョンからの変更のまとめを含めるようにしてください。しかし、コミットメッセージに含めてはいけません。 パッチの電子メールにおいて、「---」の行より上のみがコミットメッセージになりますので、ここのみがコミットされた再にgitの変更履歴となります。 この部分は、このバージョンのパッチが何をしているのかと言う自己完結的な説明でなくてはなりません。6カ月後に見直しても誰もが分かるように書かれなくてはなりません。 「---」の下でパッチ自体の上の行は、(git format-patchはdiffstatをここに挿入しますが)パッチを読んでくれる人に向けての意見を記載するのに良い場所です。「以前のバージョンからの変更点」はここに記載します。 git-publishスクリプトは、各バージョン間のまとめを追うのに便利です。 また、git-backport-diffスクリプトは、バージョン間の変更に着目しているレビュアーに役立ちます。
長い一連のパッチをレビューする時、レビュアーはいくつかのパッチにReviewed-byタグを付けて返信することができます。これは、そのパッチは独立して扱って良いことを示します(ホワイトスペースの変更のようなコードの文脈に影響しない重要でないクリーンアップなど)。 そのような返信を受け取ったら、Reviewed-byタグを手動でコミットメッセージに含め、パッチを次のバージョンにし、レビュアーがどのパッチは既にレビュー済みであるかが分かるようにします。
逆に、以前にレビューを受けたパッチを大幅に変更した場合には、Reviewed-byタグをコミットメッセージから削除し、以前のバージョンからの変更点を記載します。これによって、あなたの変更にレビュアーが注意を簡単に払えるようにします。
もしあなたのパッチが何の返信ももらえない場合には1から2週間後に「ping」を送るべきです。これは、パッチの電子メールに返信して電子メールを送ることによって行ないます。内容は、「ping」とパッチへのpatchworkまたはGMANEのページへのリンクです。 なぜ無視されているのかを再度見直すのも大切です(メンテナーをCCに入れていないとか、以前のバージョンのレビューコメントに返信していないとか)。ですが、あまりメンテナンスされていない分野では、単に見過されている可能性があります。 pingしても無視されたら、1週間後に再度pingします。 あなたは、あなたのパッチが適用されることに対して最もやる気のある人です。粘り強くなくてはなりません。
メーリングリストであなたのパッチが十分にレビューされた後、その分野のメンテナーはメーリングリストにあなたのパッチが特定の準備用のブランチに適用した旨の連絡をします。 定期的に、メンテナーはqemu mainlineにトピックブランチを集約するためのプルリクエストを送ります。 あなたがある分野のコードのメンテナーになるまで、プルリクエストを送る必要はありません。 メンテナーは、あなたのコミットをさらに変更することがあります。単純なマージ時の競合を解決するものである場合や、レビュー中に指摘された重要でない誤字脱字の修正をする場合がありますが、Signed-off-by行があなたの行に追加されます。そのメンテナーのツリーを通じて取り入れられたことを示すためです。 メンテナーのプルリクエストが難しいマージ時の競合に遭遇することがあります。このような場合には、リベースト問題の解決を手助けして欲しいと依頼されるかもしれません。 あなたのパッチが最初に良い返事をもらってからqemu.gitに含まれるようになるまで、数週間は必要かもしれません。リリースサイクルフリーズに期間に重なると、もっと長くかかるでしょう。
ピアレビューは全ての人がレビューに時間を割く場合のみ成立します。 もし全員が自分のレビューするよりも多くのパッチを提出するとしたら、パッチは停滞します。 良いゴールは、自分が提出したのと同じ数だけ他の人のパッチをレビューすると言うことです。 メンテナーほどコードベースに詳しくないからと言って心配しないでください。あなたがコードにあまり親しんでいなことにより、レビューが弱いと言うのは、完全に許されています。