2.5.3 9
ストーリー by wakatono
そろそろ入れてる人は増えるかな？ 部門より
そろそろ入れてる人は増えるかな？ 部門より
dai 曰く、 "ChangeLog-2.5.3より
- Doug Ledford: i810 audio driver update
- Evgeniy Polyakov: update various SCSI drivers to new locking
- David Howells: syscall latency improvement, try 2
- Francois Romieu: dscc4 driver update
- Patrick Mochel: driver model fixes
- Andrew Morton: clean up a few details in ext3 inode initialization
- Pete Wyckoff: make x86 machine check print out right address..
- Hans Reiser: reiserfs update
- Richard Gooch: devfs update
- Greg KH: USB updates
- Dave Jones: PNPBIOS
- Nathan Scott: extended attributes
- Corey Minyard: clean up zlib duplication (triplication..)
IDE, driverfs, extended attributes (スコア:2, 参考になる)
- IDEのドライバが新しいのにリプレースされました。LBA48に対応したほかにディスクへのアクセスする方法を近代化したようです。
- デバイスを階層的に扱うdriverfsがpciを取り込みました。mountしてみるとpciに何が付いてるかわかって面白いです。
- struct stat以外の属性をファイルに付加するextended attributesのシステムコールが追加されました。ACLとかを実装するんでしょうけど、どのファルシステムから対応するんでしょうか？
kernel 2.5 status [kernelnewbies.org]というページがあって、これから何が行われるかわかって面白いです。...Alexander Viro氏はunion mountをやる気らしい。 ...IPv6のところにJun Muraiと書いてあるのが笑える。
ChangeLogをどれだけ理解できるか (スコア:1)
毎回ChangeLogが出てくるのはいいんですが、それに書いてあることを完全に理解できる(問題を引こ起こす恐れがある場合にそれを指摘できる)人はどれくらいいるんでしょうか?
Re:ChangeLogをどれだけ理解できるか (スコア:1)
変更をした当事者しかわからないでしょう。だって、具体的にどうコードに手を入れたかがコードを見ない限りわからないんだから。実際、バージョン間のパッチを見た方が話が早い。
構造改革の理解とkernelの発展 (スコア:4, 興味深い)
null dereferenceを直したという程度の問題ならsourceを見た方がが楽です。しかし、kernelの変更には、subsystemのsemanticsやsubsystem間の関係を変革するような大きなものもあります。こういうものは大抵はsourceを見ただけではさっぱりわかりません。
ところが、このような問題についてその背景や過去の解法を知っている人にとっては、すぐに変更の影響が予想できるんです。したがって、変なことをやっていればすぐにわかります。こういう人の人数は少ないのですが、実際にkernelを良くする作業の上では中心となってやってくれます。あるいは自分が問題を解決しかけたところで時間切れになってしまった場合、他の人に丸投げということもできます(1度経験あり)。
私が恐れているのは(というより、少なくとも日本の現実はすでにそのような事態に陥ってしまっているのだが)、sourceないしはChangeLogを読んだだけですべてを理解したような錯覚に陥る人が増えることです。そういう人達は「updateしたら動かねー」「○○のヤツは危ないぞ」など、悪い情報を流したがるのですぐわかります。こうなると、中心になって作業してくれる人がただでさえ少ないのに、それをますます減らす方向に動いてしまいます。
まぁ、雑誌などにも堂々と「枯れたものを」なんて書いてある国なので期待はしていませんが、それでも1人でも本当に解かなければならない問題に突き当たった人がいたら、問題を解くチャンスを殺してはなりません。
Re:構造改革の理解とkernelの発展 (スコア:2, すばらしい洞察)
# こんな事ならモデレーション残しとくんだった... そういう人はソースはおろか、ChangeLogも読んでないのではないかと思いますが(^^;
それはさておき、そういう「悪くなった」という情報も情報としては重要だと思います。
（というかテストの局面では、そういう情報の方が大事）
もちろん、そういう情報はupstreamに還元するのが筋ですが、そのようなスキルが十分に無い人が「なんだかわかんないけど動かない」という無駄な情報を還元するよりは、そういう「現象」を報告し、ある程度解決できるだけのスキルがある人が「調査」しupstreamへ還元するというのも、upstreamの負荷を減らす一つの方法ではないでしょうか
問題があるとしたら、そういう中間的な立場の人が少ないという事でしょう。 ユーザ全員が開発者になる必要は無いでしょう。
単なるユーザであれば「枯れたもの」を使うよう勧める事に問題があるとは思いませんが...
Re:構造改革の理解とkernelの発展 (スコア:1, 興味深い)
問題を開発元へ持ち上げるというのは確かに本質的に難しい作業ではあります(日本だとなかなか実働のOSを勉強できる機会がない)。ただ、それは問題の半分にすぎなくて、難しい作業を回避してもなんとかなってしまう(「○○というデバイスは動かない」など)という問題もあります。
そうなると、何か問題に突き当たった時に、それを回避するのがいいのか、真正面から切り崩すのがよいのかという判断をしなければなりません。PC-Unixの世界だと、この判断も含めて「自分で会得せよ」となるわけですが、周りにそれができている人がほとんどいないという環境では無理があるのではないでしょうか。
私の場合は、真正面から切り崩す方を選ぶことが多かったです。個人的な事情ですが、スケーラビリティに関する問題に当たることが多かったので、「今やっておけば後が楽になる」「後には引き下がれない」と考えて対策をとってきました(現に本家のsourceにすでに入っているものもある)。
# moderationについては気にしていません。この問題はmetamoderatorたちが判断を下すことですから。
Re:ChangeLogをどれだけ理解できるか (スコア:0)
結局、head を追っかけたいなら kernel list を購読してちゃんと読んでないとダメってことでしょうな。
# Linux kernel list に heads-up がちゃんと出てるのかどうかは知らんが。
パッチが壊れているみたい (スコア:1)
linux/linux/zconf.h および linux/linux/zutil.h は、本来 include/linux/ に置くべきものと思われます。include/linux/ にコピーしたら正常に構築できたので、リリースをミスったようです。
しかし、今回のパッチは展開すると20万6千行に(汗)
Re:パッチが壊れているみたい (スコア:1)
linux/Documentation/Configure.help がなくなり、ソースの各サブディレクトリに Config.help を置くようになっています。保守性の向上が目的なのでしょう。