アカウント名:
パスワード:
Linus氏って怒ってばっかりいるような気がする。
# エアコンの壊れた車に乗って、渋滞にはまってしまわないように祈らなくては...
> Linus氏って怒ってばっかりいるような気がする。
わりと同感なんだけど、この件に関してはLinusが正しいよ。デバイスドライバのバイナリ互換性を壊さないように頑張って維持してるのに、誤解から「デバイスドライバのバイナリ互換性を捨てた」なんて書かれたら、そりゃ怒るでしょ。
デバイスドライバのバイナリ互換性を維持しているなんて、struct file_operationsのメンバーを変更して非互換をつくっておいて、よくもそんなことが言えたもんだ。
ああ、ioctl()の件ね。
それまで、linux/fs.hstruct file_operations {(略)int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);(略)}だったのを、
linux/fs.hstruct file_operations {(略)long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);long (*compat_ioctl) (struct file *, unsigned int, unsigned long);(略)}というように変更して、ドライバに対するAPIを変更したことがありましたね。
確か、
それ、ユーザーランドに対するABI互換性じゃなくて、DDI/DKI互換性(デバイスドライバのカーネル内バイナリ互換性)の件でしょう。
LinuxカーネルははABI互換性は保証してくれてるけど、DDI/DKI互換性はまったく保証してくれない。その点については、確かにWindowsやら商用UNIXやらと比べて劣ってるんだけど、それはLinuxの歴史の最初っからそうだったわけで、Miguel氏のように「when he dismissed binary compatibility for device drivers」って表現は変でしょ。dismissっていうと、それまでは存在したものを止めるってニュアンスだけど、そもそ
ドライバ周りは、細かなところで結構非互換が発生してます。Linuxがデバイスドライバのバイナリ互換性を維持しているなんて言えるのは、1)機能拡張に伴う仕様変更を非互換と認識していない人か、2)直接にデバイスドライバを操作するアプリケーションを書いていない人か、3)デバイスドライバを開発したことのない人かのいずれかだと思う。
Linus氏は、1)のタイプでしょうけどね。
ドライバ以外でも、kernelの開発コミュニティとglibcの開発コミュニティが機能拡張と互換性の狭間でバトルしていることも珍しい話ではない。
Linux kernelが保守的でバイナリ互換性を維持しているなんて言うのは、ジョークでしかない。glibcが保守的で互換性をしっかりやっているから救われているようなものである。
2.6.xのxが変更されただけでドライバのコンパイルすら通らなくなるなんて珍しくもなんともないのに互換性云々言われてもなぁ
Linuxはわりと、デバイスドライバーの構造体の途中に気にせず新しい変数突っ込んだりすることがあるので、その意味ではWindowsに慣れているとイラっとすることもあるかも。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
最近 (スコア:1)
Linus氏って怒ってばっかりいるような気がする。
# エアコンの壊れた車に乗って、渋滞にはまってしまわないように祈らなくては...
Re:最近 (スコア:1)
> Linus氏って怒ってばっかりいるような気がする。
わりと同感なんだけど、この件に関してはLinusが正しいよ。
デバイスドライバのバイナリ互換性を壊さないように頑張って維持してるのに、
誤解から「デバイスドライバのバイナリ互換性を捨てた」なんて書かれたら、
そりゃ怒るでしょ。
Re: (スコア:0)
デバイスドライバのバイナリ互換性を維持しているなんて、struct file_operationsのメンバーを変更して非互換をつくっておいて、よくもそんなことが言えたもんだ。
Re: (スコア:0)
ああ、ioctl()の件ね。
それまで、
linux/fs.h
struct file_operations {
(略)
int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);
(略)
}
だったのを、
linux/fs.h
struct file_operations {
(略)
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
(略)
}
というように変更して、ドライバに対するAPIを変更したことがありましたね。
確か、
Re: (スコア:0)
それ、ユーザーランドに対するABI互換性じゃなくて、
DDI/DKI互換性(デバイスドライバのカーネル内バイナリ互換性)の件でしょう。
LinuxカーネルははABI互換性は保証してくれてるけど、
DDI/DKI互換性はまったく保証してくれない。
その点については、確かにWindowsやら商用UNIXやらと比べて劣ってるんだけど、
それはLinuxの歴史の最初っからそうだったわけで、
Miguel氏のように「when he dismissed binary compatibility for device drivers」って
表現は変でしょ。
dismissっていうと、それまでは存在したものを止めるってニュアンスだけど、
そもそ
Re: (スコア:0)
ドライバ周りは、細かなところで結構非互換が発生してます。
Linuxがデバイスドライバのバイナリ互換性を維持しているなんて言えるのは、1)機能拡張に伴う仕様変更を非互換と認識していない人か、2)直接にデバイスドライバを操作するアプリケーションを書いていない人か、3)デバイスドライバを開発したことのない人かのいずれかだと思う。
Linus氏は、1)のタイプでしょうけどね。
ドライバ以外でも、kernelの開発コミュニティとglibcの開発コミュニティが機能拡張と互換性の狭間でバトルしていることも珍しい話ではない。
Linux kernelが保守的でバイナリ互換性を維持しているなんて言うのは、ジョークでしかない。glibcが保守的で互換性をしっかりやっているから救われているようなものである。
Re:最近 (スコア:1)
Re: (スコア:0)
2.6.xのxが変更されただけでドライバのコンパイルすら通らなくなるなんて珍しくもなんともないのに互換性云々言われてもなぁ
Re: (スコア:0)
Linuxはわりと、デバイスドライバーの構造体の途中に気にせず新しい変数突っ込んだりすることがあるので、その意味ではWindowsに慣れているとイラっとすることもあるかも。