twitter icon   twitter icon   rss icon

Linux.com Japan

Home Linux コミュニティ カーネル開発者への道 Kernel MessageにIDを!

カーネル開発者への道

『Kernel MessageにIDを!』

 以下のストーリーは、Linux Kernelが出力するメッセージにIDを ふるためのPatchをメインラインKernelにマージするために集結した、日本OSS推進フォーラム メッセージDBタ スクフォース(以下メッセージDB TFメンバーの挑戦を、『現在進行型』のドキュメンタリーで描いたものである。

  メッセージDB TFメ ンバーが、どのような目的意識でこのプロジェクトに取り組み、どのような課題にぶつかり、そしてどのようにその課題を解決していくかを描くことによって、 オープンソースコミュニティとの関わり方、オープンソースのビジネス活用の意義などを、リアリティをもって紹介するものである。


 

Act 1: Linusに挑戦!

出発点:なぜカーネルメッセージ IDが 必要か? 

  日本におけるIT産業は、SI会 社と呼ばれる企業の役割が非常に大きい。SI会社の事業を端的に説明すると、顧客の要件を聞き、その顧 客の要件に沿ってシステムを構築および納入し、その後のメンテナンスを請負う、というビジネスである。したがって、ITシ ステムのユーザである企業は、自らのビジネスのコアコンピタンスでは無いITシステムの導入・運用の大部分をSI会 社に委託し、自らはコアな事業に専念出来るというところがSI会社の価値である。

  このSIと いう事業において最もコストの見積もりが難しく、事業の成否を分けるクリティカルな要因は、システム導入後の「サポート」「メンテナンス」であり、ここの 効率化によって、企業は高い収益率を達成することもあれば、システム導入時に得られた収益も全て吹き飛ばす赤字プロジェクトとなる可能性もある。

  本稿で取り上げる「Kernel Message ID」(以下「メッセージID」) という機能は、システム障害発生時の障害原因の検索性を高めることによって、SI企業にとって最もクリティカルな課題であるメンテナンスコ ストの削減に寄与する機能であり、日本の大手SI会社が長年Linuxのメインラインカーメルに取り込まれることを期待し、また 働きかけて来た機能である。

  これほど世の中から必要とされているメッセージIDがなぜいまだにLinux Kernelの機能に組み込まれていないのか?

  そこには開発する側(Community開発者)と使う側(ユーザ企業)における『思想の違い』と いう大きな問題が横たわっている。

 

『メインライン』への遠い道のり:

  『メインライン』とはLinus Torvaldsがメンテナンスをする、Linuxの 標準のソースコードをさす。開発されたパッチがこの『メインライン』に取り込まれることにより、その修正は開発者自身がメンテナンスをずっと行っていく必 要がある「ローカル」な修正から、カーネルコミュニティによってメンテナンスがされる、「スタンダード」な修正へとなる。

  昨年日本発のプロジェクトであるTOMOYO Linuxがメインラインにマージされたが、TOMOYO Linuxのプロジェクトを率いていて、TOMOYO Linuxをメインラインに導いた原田季栄氏は、マージ以前にメイン ライン化の意義を次のように語っていた。

『現 在、TOMOYO Linuxはメイ ンラインに入っていません。メインラインに入っていないということは「ローカルな改造」ということを意味します。TOMOYO Linuxは、現 状NTTデータ が開発を行っていますが、プロジェクトが終了してしまうと誰も新しいLinuxTOMOYO Linuxを使え なくなり、質問もできなくなります。それはソフトウェアとしての死を意味します。』
Think IT掲載インタビューより引用

  従ってLinuxを多く活用し、カーネルレベルまで手を加えている企業に とっては、自社で行った修正がこの『メインライン』にマージされることは極めて重要であると言える。

  カーネルコミュニティではこの『メインライン』から派生したプロジェクトは実に800以上も存在し、日々開発プロジェクトが展開されているが、 その中でもLinuxの創始者であるLinus Torvaldsによって認められたパッチが『メインライン』にマージされ て行く。

  メッセージ IDも実はこれまで何度か『メインライン』へのマージを試みら れ、実際800あるプロジェクトの中の一つである、IBMS390の開発プロジェクトの中にはすでに取り込まれており、その プロジェクトの中では、メンテナンスが続けられている。

  それではこれまでなぜ『メインライン』へマージされなかったか。

  それはすなわちこれまでLinusにメッセージIDの 必要性を納得させるまでの説明が出来た開発者がいなかったからである。

  実際にLKML上での議論を交えてここでは紹介しよう。

 Linusの論点は次のLKMLでの一つのスレッドでの議論から判る。

フォー ムの始まり

フォー ムの終わり

Date

Thu, 23 Oct 2008 14:37:24 -0700 (PDT)

From

Linus Torvalds

Subject

Re: [GIT PULL/RESEND] kernel message catalog patches



On Thu, 23 Oct 2008, Heiko Carstens wrote:
>
> The whole point of the patch set is to add documentation for kernel
> messages that are emitted via printk. The documentation is supposed to
> help a sys admin to help understand what went wrong.

I'm still not convinced.

> Please note that this was initially an s390 only patch set but we moved
> the infrastructure to generic code since it looks like others want a
> facility like this too. iirc Andrew requested the move.

I do agree that it makes no sense as a s390 feature, but quite frankly, I don't think it makes sense AT ALL. It introduces the notion of fixed messages and people now suddenly need to worry about the hashes of the contents etc. Exactly the kind of thing that I don't personally EVER want to see, and certainly not inside the kernel.

If somebody really wants this, I seriously believe it would be better done as a separate out-of-kernel package. Because I don't think it's worth maintaining those hashed translations in-kernel, and I'm nto going to ask people to even bother.

But if it's in-kernel, other people are then going to complain about them not being maintained. And quite frankly, I'm neither willing nor
interested in hearing those complaints or making them more "valid".

So please keep the kernel message catalog external. Or try to convince me.
But don't send me a "please pull" without any explanation or any relevant convincing argument.

               Linus

 

   

フォー ムの始まり

 フォー ムの終わり

Date

Mon, 27 Oct 2008 08:05:29 -0700 (PDT)

From

Linus Torvalds

Subject

Re: [GIT PULL/RESEND] kernel message catalog patches

 

 

On Mon, 27 Oct 2008, Martin Schwidefsky wrote:

 

>  > Ok, understood. Not that the reaction surprises me, seems like nobody > likes documentation (including me). 

 

It's that I don't like out-of-line documentation. It's a damn pain to  maintain, and it's _especially_ so when it's for small details rather than  "big picture" issues. 

 

I also consider this to be _exactly_ the same issue as translating kernel  messages into another language (which people have also wanted to do),  except the "other language" is a S390-specific "odd-speak" rather than a  real language. 

 

I have to say that I also dislike the technical implementation. I don't  like having yet another printk() wrapper - your "kmsg_warn()" won't play  well with people who have messages they want to print, but that use helper  routines - or then you'd need to essentially change _every_ printk to a  kmsg_xyz().  

 

So if you want to have a hash (so that you can identify the _format_  string rather than the printed out message), I personally think you'd be  better off thinking of it purely the same way as CONFIG_PRINTK_TIME, and  just have a config option that disables or enables the hashing of the  format string, the same way we have an option for disabling or enabling of  the timestamping of the printk. 

 

I also suspect that it would be better to not _print_ it, but only put it  into the dmesg logs (the same way we do with the urgency level marker). 

 

IOW, I think we could put a few lines of code in "vprintk" that just  hashes ove 'fmt' and then adds that to the output. 

 

And as for the actual explanations: either they need to be totally outside  the kernel (in a project of their own), or they'd need to be "kernel-doc"  style things that are _in_ the source code. Not in Documentation/. Not  separate from the printk() that they are associated with.                     

 

             Linus  

 

  つまりLinusの論点としては、カーネルメッセージに『特定のIDに 紐付けられたメッセージ』という新たな概念を導入することにより、カーネルのメンテナンス性が悪化し、他のコミュニティ開発者からの理解を得られない、と いうものである。

  すなわち、今後メッセージDB TFメンバーが、Linusを説得し、メッセージIDの パッチをメインラインにマージし、かつそれを日本におけるメッセージDBプロジェクト(= mPedia)につなげるためには、以下の課題を解決する必要があると 言えよう:

l   カーネルへの変更 が、小さく、かつメンテナンス性を損なわない

l   mPediaで要求される仕様に合致している

か くして、日本OSS推進フォーラム メッセージDB TFメンバーのLinusへの挑戦は始まった。

Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ

  1. Today's Linux 2017/01/05 2017年 1月 04日
  2. Today's Linux 2017/01/17 2017年 1月 16日
  3. Today's Linux 2017/01/06 2017年 1月 05日
  4. Today's Linux 2017/01/12 2017年 1月 11日
  5. Today's Linux 2017/01/11 2017年 1月 10日

Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!