twitter icon   twitter icon   rss icon

Linux.com Japan

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

カーネル開発者への道

『Kernel MessageにIDを!』

Act2:課題解決へ

  この問題解決に向けてまず動いたのは、メッセージDB TFのメンバーであり、かつThe Linux Foundationのボードも勤める、日立製作所の橋本尚である。

  橋本はLinux Foundation Japanに向けてこう主張した。

  「メッセージIDは、日本のSIer各社にとって極めて有意義な機能となる。是非Linux Foundationで、メインラインへのマージを支援するべきだ。」

  この一言によりLinux Foundationの内部でメッセージID対 応メンバーが結成され、日本のメッセージDB TFと連動する形でプロジェクトが始まった。

誰 がやるか? 〜結局問題意識を もつ者が動くしか無い〜:

  「カーネルメッセージにIDを」の旗印の元集まったメッセージDB TFLinux Foundationスタッフか ら構成されたプロジェクトメンバーは、まずメインラインへのマージに向けて何を行う必要があるかを検討した。

  その結果概ね次の3つが要求されるアクションであると結論付けた。

1.       Linusを説得しうるパッチの仕様決定

2.       パッチの開発

3.       LKMLへの投稿とLinusおよび他のコミュニティ開発者とのタイムリーなコミュニ ケーション

  「仕様を決め」「開発を行い」かつ「Linusと折衝する」という極めて大きな仕事を「誰かが」行う必要 がある。

  このメッセージIDプロジェクトは「オープンソース」のプロジェクトである。 従って本質的にはボランティアである。

  メッセージDB TFメンバーも、各所属企業での業務を抱えており、その傍らこ のプロジェクトに取り組む訳である。

  当然「誰がやるか」という点が大きな問題となる。

  一方どんなオープンソースのプロジェクトでもそうであるが、本来であれば一人(乃至は一社)で100パーセントのコストを負担しなければならない開発行為を、 例えば5名(乃至は5社) 集うことによって、開発に掛かるコストを1/5に削減することができ、かつ必要とされる成果物の恩恵を享 受することが可能である。

  加えてメインラインにマージされることによって、メンテナンスに掛かる費用を劇的に低減することが可能である。

  これがすなわち企業にとってオープンソースを活用する最大のメリットである。

  今回の場合、メッセージDB TFのメンバーは、このオープンソース活用メリットを享受する ために「自ら動く」という覚悟を決めた。

  確かに大変な作業である。

  これまで海外の精鋭技術者がLinusに提案したにも関わらず受け入れられなかった提案を、再度 新たなロジックとパッチを以て再提案するのである。当然ながら、ハードルは高い。

  それでもメッセージDB TFがこれに取り組むのは、TF参 加メンバー企業にとって、この機能が各社のシステムサポートの効率を上げ、顧客満足の向上とサポートコスト低減につながる極めて重要な機能であり、この機 能をメンバー各社とコストを負担しながら開発することに、営利企業としての大きなベネフィットがあるからである。

  とにかく、メッセージDB TFは、自らの力でこの難題に取り組む覚悟を決めた。

 

最初の課題:Linusを説得できる仕様は何か?

  さて、メッセージDB TFメンバーにとっての最初の課題は何であったか?

  それは紛れもなく、Linusを説得しうるパッチの仕様を決めることである。

 TFメ ンバーは、リーダーであるユニアデックスの高橋秀樹を中心に検討したが、この仕様決めプロセスのみならず、今後のパッチ開発やLKML投稿に向けて、カーネルを知り、コミュニティを知り、かつLinusを知る「アドバイザー」を必要としていた。

  そこでLinux Foundationは、ext3ファイルシステムのメンテナであり、またLinus同様にLinux Foundationのフェローを勤めるTed Ts’oにメッセージDB TFへの支援を要請し、Tedはこれを快く引き受けた。

  ここに日本OSS推進フォーラム メッセージDB TFThe Linux Foundation(米 国・日本)、それにTed Ts’oを巻き込んだ、企業、国境、言語の枠を超越したプロジェク トチームが誕生した。

  仕様に関するTedの最初のアドバイスは次の通りであった。

Hi all,


Having re-read the discussion on LKML from the previous attempts to
provide this, let me suggest something which I think might be
acceptable to Linus ---
(中略)


The basic idea is that we make printk a macro, e.g:


#ifdef CONFIG_PRINTK_CONTEXT

#define printk(fmt, ...) printk_context(__DIR__, __FILE__, __LINE__, \


                                       __func__, fmt, ...)


#else
#define printk(fmt, ...) __printk(fmt, ...)

#endif

The idea is that we want to eliminate, as much as possible, the need
for any changes to any kernel source files outside of kernel/printk.c
(and even there we keep the changes as small as possible).  __DIR__ is
somewhat problematic, in that it is not something provided for by the
C compiler.  To get this we will need to make a change to the kbuild
system so that it gets defined to be the directory name of the source
file and included as a option to the C compiler (i.e., -D__DIR__=fs/ext4).

printk_context can then print the something like the following:


[CRC_fmt:CRC_PATHNAME_FILE:LINE] printk message


... where CRC_fmt is the crc32 of the format string (rendered as 8 hex
digits), CRC_DIR is the crc32 of the concatenation of __DIR__, "/",
and __FILE__ (rendered as 8 hex digits), and the line number is
__LINE__ in decimal.

 

(中略)


Do you think that this gives you the hooks so you can do what you want
to do?   If not, what aspect of your requirements does this not meet?

Best regards,       


                                               - Ted

つ まり、Tedのアドバイスは、次の通り: 

l   カーネルのソース ファイルへの変更は極力行わないか、行うとしても最小限に留めるべき

l   上記の観点から、kbuildへの変更を行う

  上記のTedのアドバイスを受けて、日本側でもTFメ ンバーで集まり、考えられる仕様の検討に入った。

  本来のLKMLでは、一つの議論に対して実にスピーディに議論が展開され る。しかし、今回のTed Ts’o相手の「疑似LKML」では、Tedからメールを受けたTFメ ンバーは、Face-to-Faceで集まり、アイデアを出し合い、意見をすり合わせてTedへメールの返信を行う、というとても冗長なプロセスではあ るが、日本人がLKMLへ投稿するまでに、まずはこのように、実際のコミュニティ 開発者とLKMLの外で協議を行い、自らの世界の距離感を把握し、自信をつ ける、という段階が必要なのでは無いかと思われる。

 

日本側の仕様案:

  さて、Tedからのアドバイスに対して、上記の通り、TFメ ンバーで協議を行い、そのTedとの何度かのメールの遣り取りの結果、TFリー ダーの高橋より、次のようにTedへ仕様の提案がなされた。

(前略)

We assume that the message ID will be printed out on the serial console. mPedia (Our web based online Message Database) will have the same hash mechanism inside mPedia to have the same message ID as the kernel.
We're not willing to have any special output from the kernel.

(中略)

The goal is not only the translation.
We'd like to provide information including the description and recovery action with the message ID. It's easy for us to find the information if we can use the message ID.
For example, mPedia will provide the following information when I searched the message by the words like "reservation conflict":

----------------------------
Mssage
scsi%d (%d,%d,%d) : reservation conflict

Arguments

host
    SCSI Host No.
channel
    SCSI Channel No.
id
    SCSI ID
lun
    SCSI LUN(Logical Unit Number)

Description
  When the SCSI (Small Computer System Interface) device has been reserved by other application host, and another application host was going to use the device, the message is outputted. The SCSI reservation is usually used for exclusive access to a joint disk between systems which constitute a cluster machine. In case of a disk being reserved in one system, any commands fail entirely from another system to the disk, and the RESERVATION_CONFLICT error occurs.

Category
  (Warning)

Action
  Because somebody reserves the device, it needs to search the object.
  In case of tearing away the reservation from other system by all means, the reservation state is canceled by sending DEVICE_RESET or BUS_DEVICE_RESET to the device.
---------------------------

We must find our expected "reservation conflict" message among other "reservation conflicts" messages because there's no message ID in the kernel.
We don't have any intention about robotic operations by untrained workers.


(中略)

We'd like to have the kernel message manual with the message ID because it will be easy and fast to find the message information.
Our goal is not the roboticized procedure manual.


>> However, it is not good if keeping identical requires the big
>> kernel changes.
>
> Well, the 32-bit CRC will be kept identical as long as the format
> string doesn't change.  Of course, there will be some collisions;
> given that there are approximately 75k printk statements in the
> kernel, which is comfortablely over the 2**(n/2)== 65,536 messages
> needed to brute-force general a collision using the birthday paradox;
> hence, there will be collisions.  But when combined with the pathname,
> line number, and function name, that should be sufficient for the
> system to give an exact match if the kernel version hasn't changed,
> and if the kernel code has changed, it becomes possible to
> semi-automatically map the printk information to a specific message
> catalog ID.
>

I think we can accept the collisions in the above rare cases.
I need to talk to Japanese members about an exact match between the
different versions. I suppose we might forget the exact match.


> It also allows us to do other things.  For example, if the idea is the
> automated procedure manual, there could be default message id which a
> replacement sysklogd could print out if there is an unknown error
> message coming from an ethernet driver; i.e., it's an unknown CRC
> code, but we know from the pathname that it's the ethernet driver.
> This default message ID could tell the operator could be asked to
> wiggle the ethernet cable, or unplug and plug it back in, etc.
>

Thank you for your idea but our goal is not making an automated
procedure manual.


>>     -  What is the best way for the next step?
>>        Making a prototype patch we'd like to have and sending it to
>>        you for having your comments, or something else?
>
> I think a prototype patch would be the next step, yes.  I think it
> should be relatively easy to do....
>

I understood.


Thank you very much for your kind help.


Best Regards,


Hideki Takahashi

  上記のメールスレッドで判る通り、メッセージIDのパッチ仕様をあくまでも、メッセージDB TFの最終的な目標である、mPediaの設計に合うように仕様が提案されている。 

  実はここがオープンソースの企業利用として重要な点である。

  すなわち、今TFメンバーが苦労してパッチを開発し、メインラインに取り込 まれた結果、すなわち世界中の誰もが利用可能な機能となる。一見するととても損な役回りである。

  しかしTFメンバーは自らパッチの仕様を決め、開発した結果、メイン ラインにマージされるパッチの仕様は、正にTFメンバーにとってもっとも都合が良い仕様となっている。

  オープンソースの世界で、最もコミュニティに貢献している企業が実際にもっともベネフィットを享受できている背景にはこういったメカニズムの存在があるこ とを忘れてはならない。

 


Linux Foundationについて

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

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

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

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

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

乞うご期待!