Linuxはｶｰﾈﾙからﾄﾞﾗｲﾊﾞを完全分離する時が来たね
■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin
2012/03/12(月) 04:08:04.12ID:khwvZHK+0002login:Penguin
2012/03/12(月) 04:16:00.05ID:9YevqZjUバイナリーとしては切り離せるようになってるけど、昔から
0003login:Penguin
2012/03/12(月) 04:20:25.42ID:khwvZHK+3月31日、LinusはLinuxカーネルのメーリングリストに宛てたメッセージで
「つまり私が言いたいのは、ARMデバイス用のドライバを闇雲にLinuxカーネルに
加えるべきでないということだ」「なぜなら、それは動かないからだ。長期的に見れば、
これらの変更はメンテナンスできないゴミだ。」「カーネル内に組み込むべきではない」と述べており、
4月18日には「無意味なプラットフォームのコードが果てしない程あるというのは
問題だってことに皆気がつかなくてはならないし、唯一私にできることといったら
『直す努力を怠るようなら、お前達から離れるぞ』と言うことだけだ。最終的にはそうすることになるだろうが」と
強気な姿勢を崩していない。
ARM用Linuxカーネルを開発するLinaroのDavid Rusling氏によれば、新カーネルに対して
およそ70,000ものARMコードが追加されるのに対し、x86コードはたったの5,000程
しか追加されていないとのこと。Torvalds氏の苛立ちはもっともであると思われる。
0004login:Penguin
2012/03/12(月) 04:34:51.12ID:c7mzFDkoカーネルモジュールはカーネルとファイルは分かれていても、その特定のカーネルのバージョンに密接に依存しすぎていて
カーネルとドライバが分離しているとは言いがたい。
ファイルが分かれているだけで密接に癒着している。
カーネルのバージョンがわずかに上がっただけでもカーネルモジュールはエラーを出して読み込まない。
強制的に読み込ますオプションはあるが動く保証はないし実際に動かないことも多い。
Linuxのドライバにはカーネルのバージョンに格バージョンに対してのバイナリ互換が全く無いということだ。
おまけにソース互換すらあまりない。
0005login:Penguin
2012/03/12(月) 04:37:34.81ID:9YevqZjU下位互換性が無いようにしてるのは、わざとじゃないの
0007login:Penguin
2012/03/12(月) 09:13:20.62ID:L5BkpBqn0008login:Penguin
2012/03/12(月) 11:40:09.36ID:SvjO9eMj0009login:Penguin
2012/03/12(月) 11:42:31.66ID:fAuugTIpカーネルを構成しているファイルが１つとカーネル空間で１塊は
また意味が違うと思うが。プラットホームごとに明らかに無駄な
部分がリンクされないカーネルが自動で作れればいいんじゃね？
起動時にメモリ上に読み込まれなければHDDの中にあったところで
そんなに問題じゃないと思うけどな。
0010login:Penguin
2012/03/12(月) 12:51:09.79ID:yRRdLxRf0011login:Penguin
2012/03/12(月) 13:36:52.99ID:Er/NhAVuドライバーのいろいろな構造体（テーブル）をカーネルのバージョンが上がるたびに
変更するんだもの、そのたびにドライバーのソースの変更が必要になる。
Windowsは嫌いだがこういう点はWindowsを見習って欲しいね。
FreeBSD系はカーネルのバージョンがちょっと上がったくらいでドライバーのソース
の変更が発生することはめったにないと思うのだが…
0012login:Penguin
2012/03/12(月) 14:05:44.08ID:9YevqZjUそういう状態が嬉しい側？
0013login:Penguin
2012/03/12(月) 15:08:17.12ID:0vI/GQmaカーネルソースに入れる必要はないと思うけど
0014login:Penguin
2012/03/12(月) 16:01:28.35ID:Er/NhAVu0015login:Penguin
2012/03/12(月) 18:14:09.59ID:1NTMdULcちゃんと動かすためにいつまでも古いカーネルを使い続けてもいいの?
そのためにいつまでも古いパソコンを使うことにもなる。
0016login:Penguin
2012/03/12(月) 18:16:57.91ID:9YevqZjU見られたくない事でもしてるのかね？
0017login:Penguin
2012/03/12(月) 18:39:24.19ID:dUxfatOt今でも十分柔軟性があるとは思うけどね
プロプライエタリなドライバが少ないのは実装よりシェアの問題だし
0018login:Penguin
2012/03/12(月) 19:33:56.10ID:0vI/GQmaメンテ嫌ならパッチ提供って何のことだ？
ニーズのないドライバでもマージしたらカーネル維持の仕事がムダに増える
そんなアホな作業が増えたらやってられんって話だと思ったが
0019login:Penguin
2012/03/12(月) 19:50:44.51ID:9YevqZjU0020login:Penguin
2012/03/12(月) 20:17:33.89ID:9osQBCTiカーネルのバージョンアップと共にソースを書き直してコンパイルし直すというメンテを必要としているLinuxカーネル側の設計ミスだろうこれは。
メンテ、メンテって言っているやつバカ?
バグがないのならメンテの必要ないシステムを考えるべきだ。
0021login:Penguin
2012/03/12(月) 21:01:13.06ID:0vI/GQmaそれとどうでもいいドライバのマージや保守は別の話だろ
0022login:Penguin
2012/03/12(月) 21:03:00.08ID:9YevqZjU0023login:Penguin
2012/03/12(月) 21:55:50.53ID:khwvZHK+ドライバとドライバの間に入れて、別のドライバを拡張したりする奴。
OSとドライバのインターフェースがきっちり決まってるからこそ、
このように間に割り込ませる汎用の方法ができるんだよね。
Linuxだとドライバに特定の機能を追加しようとしたら
ソースコードにパッチを当てて修正という作業になる。
0024login:Penguin
2012/03/12(月) 22:03:39.24ID:khwvZHK+> メンテしたくないなら、patch提供して取り込んでもらえばいいのに
> 見られたくない事でもしてるのかね？
だから、そのpatchを誰がメンテするんだってこと？
ドライバに関しては、カーネルのバージョンが上がるたびに
メンテしないといけない状況になる。
取り込んで終わりというわけにはいかない。
たとえ不具合がなくとも、メンテが必要。
こんなんじゃニッチなドライバはLinuxでは使えなくなっていくよね。
そもそも、>>20がいうように、メンテが必要なのがおかしい。
しっかりドライバのインターフェースを定めておけば、
カーネルがメジャーアップデートでもしない限り互換性が保てるはず。
そうなればメンテする必要も少なくなってメンテナがつかれることも減るだろう。
0025login:Penguin
2012/03/12(月) 22:11:29.67ID:Er/NhAVu積極的にドライバーのソースを直して新機能に対応させるのだが、そうでなくただ構造体が変更に
なっただけでドライバー自体は安定動作しているのにソースコードを修正する作業が発生するのは
メンテナーにはちっともありがたくない。
0026login:Penguin
2012/03/12(月) 22:15:42.65ID:Er/NhAVu＞しっかりドライバのインターフェースを定めておけば、
＞カーネルがメジャーアップデートでもしない限り互換性が保てるはず。
なんかしらんがカーネルのバージョンがちょっと上がっただけで
ころころテーブルフォーマットを変更するんだよな。
なんか意味があって改良になっているんだろうがよくわかんない。
0027login:Penguin
2012/03/12(月) 22:17:00.44ID:khwvZHK+真剣に考えるときがきているのだろうな。
0028login:Penguin
2012/03/12(月) 23:20:31.03ID:baGPtD41それはいいとして
こんな所にスレ立ててまで主張したいことがあるんなら
コミュニティーとかに飛び込めばいいのに
0029login:Penguin
2012/03/12(月) 23:28:36.22ID:L5BkpBqn0030login:Penguin
2012/03/12(月) 23:31:01.11ID:HoNJEposモノリシックでも、せめてNetBSDみたいにMI/MDを分離すべきだったな。
単なるゴチャ混ぜ、gdgdなだけのLinux kernel...
Linusも20年前と言ってることが正反対だしぃ。
0031login:Penguin
2012/03/12(月) 23:53:17.74ID:baGPtD41この板に張り付いて書き込んでる人達にも同じ臭いを感じるぜ
0032login:Penguin
2012/03/12(月) 23:59:49.81ID:a3oLpxGm正式なLinuxカーネル開発会社を起業すべき。
そんで、企業サポートの名のもとに、まともなABIと完全なバイナリ互換を補償しろや。
0033login:Penguin
2012/03/13(火) 00:08:36.11ID:KDpxLFscあめぞうからパクった2chみたいに。
0034login:Penguin
2012/03/13(火) 00:24:43.44ID:KDpxLFsc0035login:Penguin
2012/03/13(火) 00:41:03.14ID:XEqUJYrfそしたらハードウェアメーカーもビジネスチャンス増えるでしょ。
それか、Linuxのほうが、Windowsのドライバをそのまま使える仕組みを入れればいいんじゃないの？
0036login:Penguin
2012/03/13(火) 01:16:47.23ID:lDK2KLr40037login:Penguin
2012/03/13(火) 01:42:05.91ID:8AsNMusWはあ、いい加減なドライバー作りましたって言ってるのか？
一時、ドライバ作ります的な流れがあったんだけど、kernel方面
0038login:Penguin
2012/03/13(火) 02:09:49.49ID:nKr+C/4Qハードの方をどうにかしようとしたら、例えばアナログラジオみたいに
プロセッサなんて使いませんというくらいのものにしなきゃいけない
だろうから無理だろうけど、ドライバの無い状況を想像するのは可能。
要するにアプリが直接ハードを叩く。Xサーバーがグラフィックカードを
音楽再生アプリがサウンドカードを、ライティングソフトがドライブを
直接制御するようなことを考えれば想像し易い。
ただしアプリが占有すると困るものも多々あるので、各ハードウェア毎に
専用の制御プロセスがメーカー等から提供されて、それらがプロセス間
通信でやりとりしながら協調動作する形に落ち着く。
それなんてマイクロ（ry
0039login:Penguin
2012/03/13(火) 02:43:16.35ID:SuHCuBnKカーネル開発スタッフのヒエラルキーも崩れてしまうんではないの？
0040login:Penguin
2012/03/13(火) 04:35:00.62ID:1fFC/8Hu0041login:Penguin
2012/03/13(火) 04:36:33.75ID:8AsNMusW0042login:Penguin
2012/03/13(火) 11:57:40.23ID:4opldOAK＞要するにアプリが直接ハードを叩く。Xサーバーがグラフィックカードを
＞音楽再生アプリがサウンドカードを、ライティングソフトがドライブを
＞直接制御するようなことを考えれば想像し易い。
それをしたくないからドライバーあるんじゃないの。
たとえばサウンドカードなんて無数にあるのにアプリが全部対応できるわけない。
0043login:Penguin
2012/03/13(火) 11:58:25.06ID:4opldOAKWindowsがそれやってるな
0044login:Penguin
2012/03/13(火) 16:20:09.94ID:qixrR3enkernel.orgで行われていた議論の論点と、滅茶苦茶ずれてる。
というか、ほとんど関係のない、勘違い話してる。
0045login:Penguin
2012/03/13(火) 17:00:58.93ID:dBuLw4viおいおい、kernel.orgの議論なんて知ったこっちゃないさ。当たり前だろ
それ程面白くないしタイトル見て分かる通りこのスレはネタスレだから
0046login:Penguin
2012/03/13(火) 17:17:18.84ID:ja3xvS7Z0047login:Penguin
2012/03/16(金) 16:45:10.86ID:DsuwJYoU(なんかワイヤレスLANがらみに手が入ったようなんだが)
うちのPCのRHINE2(NIC)がIRQエラー吐きつづけている。
これってやっぱカーネルにドライバがはっているせい?
RHINE2のドライバのソースは2003年製で
そのあと更新されている形跡がないのだが。
もはやコンパイルが通らない。
どうしたものか…
まぁ、使ってないからいいんだけど
syslogがうざくて。
[ 19.627065] via-rhine 0000:00:12.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[ 19.627408] via-rhine 0000:00:12.0: eth1: VIA Rhine II at 0x*******, xx:xx:xx:xx:xx:xx, IRQ 23
...
[ 5683.476022] Polling IRQ 23
[ 5684.476020] Reenabling IRQ 23
...
Message from syslogd@localhost at Mar 16 16:38:01 ...
kernel:[ 5743.020899] Disabling IRQ 23
0048login:Penguin
2012/03/16(金) 17:44:14.09ID:h0xF1Usy日本語でおけ
0049login:Penguin
2012/03/16(金) 18:12:20.00ID:bhRIzDAZここ質問スレじゃないよ。
0050login:Penguin
2012/03/16(金) 18:48:00.12ID:QO1H+a6Q今まで使えているデバイスドライバを使い続けたければ
カーネルは更新してはいけない。
こういうトラブルが嫌な人のために有料のLinuxの高機能ディス鳥であるWindowsが存在する。
0051login:Penguin
2012/03/16(金) 19:38:23.27ID:+QBbOQyJ解決と言うか、オンボNICならBIOS等でDisableにしちゃうとか。
0052login:Penguin
2012/03/16(金) 21:31:08.53ID:DsuwJYoUそれだっ!!。なんで気づかなかったんだろ。
つーかこのマザボは、もともとカーネル更新の度に
NICのドライバをコンパイル・インスコするのが面倒で
普通に認識されるの別の1000円蟹NIC差してたんだった。
忘れてたよ。
でもここ数年は知らんうちに両方のNICが動くようになってて
カーネルに取り込まれたのかねぇとか思っていたんだけど。
ありがとね。
まぁ、近々マザボ交換する予定なんだけどね。
さて、今度は(チップセット)ドライバのおかげでマザボの交換だけするか
OSの再インストールにするか悩みどころだよ
カーネルとドライバの分離ってありかもしれんね。
0053login:Penguin
2012/03/16(金) 23:11:02.44ID:TaPzQg9u0054login:Penguin
2012/03/17(土) 08:06:41.68ID:S+VvOKbMそれ、RH厨しかしらない専門用語
0055login:Penguin
2012/03/17(土) 14:44:08.86ID:pw1PzXpkLinuxカーネルに入れるなってことだろ？
昔のGPUドライバ。今メンテされてないよね。
GPUドライバもカーネルに入れるべきではないんじゃね？
0056login:Penguin
2012/03/17(土) 14:51:24.92ID:pw1PzXpkいち早くそれに対応した、無名のメーカーがある。
将来このメーカーはUSB4.0で大きくなるかもしれないが、
Linuxは大きくなるまで、サポートしないわけだよね。
だって他のメーカーが製品作って、すぐ誰も
メンテナンスしなくなるかもしれないじゃん。
リーナスの考えは、Linuxは新しいデバイスに対応しないって
悪い流れを更に推し進めるものになるよ。
Linuxは新しいのも古いのもメジャーなもの以外は対応しない
0057login:Penguin
2012/03/17(土) 19:08:10.44ID:oP2ZyJls0058login:Penguin
2012/03/18(日) 22:28:14.24ID:jlvZAE6y>>3の話？
ぜんぜん違うよ。
これは元の報道自体が説明不足でミスリーディングしてんだけど、
Linusが問題にしていたのは、ARMの組み込み用のSoCがたくさんあって、
そのSoC専用の、主にペリフェラル用の、コード群を、抽象化して共通化せずに、
SoC毎に別のドライバとして提供されたのを、マージしようとしていたこと。
組み込みCPU作った奴らのコードが場当たり的で、抽象化が甘いから起きた問題。
Linuxカーネル構造の固有の問題じゃないし、kernel.orgの体制の不備でもない。
指針ドキュメントが不足していたということは言えると思う。
Linusはトサカにくると言葉が荒くなって説明が下手になるのも祭りになる原因の一つだが。
0059login:Penguin
2012/03/18(日) 22:34:34.46ID:MmrcJrwnえっと、ARMで抽象化は無理だよ。
ARMってのは、基本はあれど、それに対して
無限にあるいろんな拡張を施して製品にする。
だから製品毎に全く違うものが出来上がる。
http://pc.watch.impress.co.jp/docs/2009/0312/hot601.htm
逆にARMのビジネスは、差別化の戦略にある。同じARMコアを採用していても、
A社の最終製品とB社の最終製品は互換性を持たない。ライセンシーごと
、あるいはプラットフォームごとに差異化された世界だ。
たとえばTIのOMAP用に書かれたソフトウェアが、NVIDIAのTegraでそのまま動いたりはしない。
もちろんプロセッサコアが同じアーキテクチャだから、注意深くプログラミングすれば、
他社のプラットフォームで動作するソフトウェアを制作することは不可能ではないが、
それはSoCに集積されたDSPやその他のI/O機能を利用しない、非効率なものになってしまう。
0060login:Penguin
2012/03/18(日) 23:08:10.42ID:4+k9wvvvその細かい差異を吸収して互換性を高めるためにOSを載せるんじゃないの？
同アーキテクチャ内の製品ごと柔軟に対応するためになるべく象徴化するわけで
もしも組込み等で独自の機能を使いたければソフトウェアの提供側でソースを修正するか、
それこそ独自のファームウェアでもいい
0061login:Penguin
2012/03/18(日) 23:24:31.81ID:MmrcJrwnPCってのはPC互換機とも言われるように、
ハードウェアレベルで細かい差異を吸収している。
ARMではそれがない。
だから、PCとCPUが同じだけどアーキテクチャが
違うものとして、昔NECのPC-98シリーズってのがあったけど、
ARMはそれと同じで、A社製ARM、B社製ARMといくつも
違うものが存在する。
それを単一のOSでサポートするならば、A社製アーキテクチャ、
B社製アーキテクチャって、アーキテクチャごとに対応しないといけない。
互換性がないのだから、ARMというくくりで一つにはできない。
0062login:Penguin
2012/03/18(日) 23:46:48.63ID:Ly5bsK+Q周辺機器ごとに違う。
0063login:Penguin
2012/03/19(月) 02:05:36.83ID:43FlxjNBコード見ればわかるけど、そういうレベルじゃないんだよ。
出来る抽象化が行われてないコードがマージされようとしていた。
ドライバにすべき部分がもっとコアの部分のパッチになっていたり。
0064login:Penguin
2012/03/19(月) 02:06:52.16ID:43FlxjNBMicrosoftのSoCは固定してサポートする方針だけど、
>>61で言うようなレベルじゃないコードがマージされようとしていた。
0065login:Penguin
2012/03/19(月) 03:41:11.02ID:2mUIztoh0066login:Penguin
2012/03/19(月) 05:19:09.76ID:BIu6/OgO0067login:Penguin
2012/03/19(月) 20:13:28.98ID:/cGywOeJ0068login:Penguin
2012/03/19(月) 20:28:31.61ID:TmtIccbz日本語って難しいですね
0069login:Penguin
2012/03/19(月) 20:40:21.33ID:fHtsMJFS0070login:Penguin
2012/03/20(火) 01:53:44.86ID:oOb/xGv+コミュニティはグダグタ、ソースはごちゃまぜ。 誰も根本的な設計ミスを認めようとしない。
そこらのゴミかき集めてもゴミの山にしまならない。
臭いから、一から作りなおせよ。
0071login:Penguin
2012/03/20(火) 01:56:52.47ID:oOb/xGv+リリース前にDRぐらいしてんだろうな？
0072バイさるマスター
2012/03/20(火) 02:01:13.33ID:RIu4mvwJ0073login:Penguin
2012/03/20(火) 02:17:42.55ID:+/tay6Np0074login:Penguin
2012/03/20(火) 03:56:49.13ID:1Swu4Na5サンプルを用意しないからコいうことになる。
いい加減その場のノリで修正するのではなく
修正が入らないような設計に変更しろ。
ドライバは、どのバージョンのどのディストリの
Linuxでも共通に使える。が原則だ。
0075login:Penguin
2012/03/20(火) 03:58:57.12ID:+/tay6Np0076login:Penguin
2012/03/20(火) 04:43:23.21ID:yCFwZRJs職を奪われたプロプラ系元開発者か、簿給でコキ使われているネガキャン要員か
0077login:Penguin
2012/03/20(火) 04:47:17.46ID:ntlASaje0078login:Penguin
2012/03/20(火) 05:28:25.25ID:1Swu4Na5毎度毎度修正がはいって
互換性がなくなるようなものの
どこが標準化されてるって？ｗ
0079login:Penguin
2012/03/20(火) 05:30:01.72ID:+/tay6Np?
0080login:Penguin
2012/03/20(火) 05:31:42.25ID:1Swu4Na50081login:Penguin
2012/03/20(火) 05:33:05.54ID:+/tay6Np0082login:Penguin
2012/03/20(火) 05:38:48.05ID:ntlASaje> なんでLinuxは毎度毎度再コンパイルが必要なんだろうねｗ
え？
0083login:Penguin
2012/03/20(火) 05:48:39.67ID:1Swu4Na5カーネルがリリースされる度にリビルドする必要がある。
モジュールのビルドはカーネルソースコードに含まれる
デバイスドライバに対するものとカーネルソースコードに
含まれない外部のカーネルモジュールに対するものの2通りあるが、
いずれもカーネルビルドのインフラを利用している。
通常、カーネルソースコードに含まれる一部のデバイスドライバは
カーネルコンフィグレーション(Kconfig)にてカーネルに直接静的リンクするか、
もしくはモジュールとして構築するかのいずれかを選ぶことができる。
モジュールとして構築することを選択した場合、カーネルソースのMakefileには
modulesというターゲットが存在し、予めこのディレクトリでカーネル
（に直接関係し、カーネルイメージの生成前段階のファイルvmlinux）を作成した後、
このmodulesターゲットを実行する事でモジュールのビルドと依存関係の解決用ファイルが生成される。
そして、make installを実行すると、システムにカーネルとモジュールを同時にインストールする。
0084login:Penguin
2012/03/20(火) 05:50:50.97ID:1Swu4Na5すなわち、カーネルのバージョンが異なれば内部のデータ構造や機能に差異があり、
非互換問題を発生する可能性がある。
Solaris、WindowsといったOSでは、カーネルのAPIとABIは
比較的安定に保たれており、このような問題を回避している。
0085login:Penguin
2012/03/20(火) 05:57:13.14ID:ntlASaje堅牢性を求められるからこのような規約があるわけで
君がバイナリレベルでの互換を望むならWindowsでも使ってればいいんじゃないの？
0086login:Penguin
2012/03/20(火) 06:13:17.23ID:CWRZW1dS0087login:Penguin
2012/03/20(火) 06:58:00.16ID:oCDgHpi9だからドライバのメンテナンスって作業が必要になる。
それが嫌だからカーネルに含めようとするんだろう。
一旦カーネルに含まれてしまえば、自分でメンテナンスル必要なくなるからな。
しかし根本的な問題は、ドライバのメンテナンスが必要とされる頻度が
高いってことだ。APIやABIが安定してないからね。
安定させれば、ドライバのメンテナンスを必要とせずに長期間使えるが、
そうすると今度はクローズドなドライバが増えるだろう。
Linuxはこのジレンマから抜けださないといけない。
おすすめはクローズドなドライバを認めて多数採用するってことだが。
0088login:Penguin
2012/03/20(火) 07:07:42.60ID:oCDgHpi9Windowsなんか、クローズドだから故に
パッチというものはまず存在しない。
だからパッチじゃなくてもドライバだけで実現可能なように
OS自体が柔軟な拡張性を持って設計されている。
Linuxがこのレベルに到達できるのはいつだろうね。
0089login:Penguin
2012/03/20(火) 10:37:29.12ID:yCFwZRJs>おすすめはクローズドなドライバを認めて多数採用するってことだが。
なんだ、これが言いたいだけだったのか、、、
”ドライバが不安定””しばしば書き換えなければいけない”といった文言が出てるけど
具体例は一度も書き込まれず。 ネガキャンにしても読む意義の少ないレスだな
0090login:Penguin
2012/03/20(火) 11:46:07.07ID:VMGHwWVq> Linuxがこのレベルに到達できるのはいつだろうね。
難しいんじゃないか？Windowsのクローズドな所があるが故に
いくらでも誤魔化せた。Win98とNT,2kは別物なのにAPIを
極力共通化し、カーネルだけさっと入れ替えた。
さらにドライバのインタフェースまで作って、ドライバ周りの作業を
カーネルの開発の作業から外へ追い出した。これはOSSには無理。
始めから設計しておかないといけない。
もしやるなら、ドライバインタフェースのレイヤを設けて、そこで
標準化する必要がある。コミュニティにそこまでリソースを掛けられるかどうか。
0091login:Penguin
2012/03/20(火) 12:09:04.47ID:Hwwj1hKOを提供してソースの一部（無償）を共有させることで全体のバランスを
保っていたと思うよ。
ハードウエアの特徴を個々に追加するのではなく、最初から拡張可能な
ゆとりがある設計は性能には繋がらない面があるがマイクロソフトは
その辺が非常に上手じゃないかとおもう。
ＮＴのビデオシステムは当初、ユーザーモードで動くサブシステムで
非常に遅かったから次期でカーネルに組み込んだ。その後もカーネルだけで
は速度が遅いのを改良するためにＤｉｒｅｃｔハードウエア関係の
拡張を繰り返してきた。
ハードウエアの抽象化とアプリケーションレベルでのハードウエア末端
の利用を同時にするのって間違った働きを完璧に検閲できないと無理
なんだろう。ドライバーを作った人がドライバーのＢＵＧ利用をさせない
為のコードを書き、パラメータの組み合わせ全てで動作を保証する
動作テストプログラムなどを同時に設計するのは金と時間がかかるんだろうね。
0092導入犬
2012/03/20(火) 13:36:43.14ID:88ub99EO0093login:Penguin
2012/03/20(火) 23:18:34.46ID:Sbz1ewXy0094login:Penguin
2012/03/21(水) 00:31:39.80ID:DL5Rb0HD0095login:Penguin
2012/03/21(水) 00:56:22.11ID:7Tu8TQrwOSSか企業かの問題じゃないと思うよ。
コミュニティのやる気の問題。
パクリしかできないハッカーばっかりだから、設計とかしたことないだろ
0096login:Penguin
2012/03/21(水) 01:01:08.88ID:7Tu8TQrw0097login:Penguin
2012/03/21(水) 03:01:29.68ID:qHV3VV6g「GPLなんてヤダ！ GNUなんてなくなっちゃえ！！」 いいたいだけなんだよ。
もうプロプラの流れには戻らんし、BSDじゃ企業間のソース共有に不公平を生む
から現在のような競合他社が切磋琢磨しながらも、互いの成果を土台にして
ともに上を目指すような流れは起きにくい。
iPad向けのミニゲーム、便利アプリ開発するにはいいんじゃない？ プロプラもBSDも
0098login:Penguin
2012/03/21(水) 05:29:32.90ID:/tI1Iw/6> *BSDでできてることが、Linuxでできないんだから
> OSSか企業かの問題じゃないと思うよ。
BSDには元々そういう設計思想が入っているじゃないの？
だからマイクロカーネルのMachはBSDサーバが標準になっていた。
後から作り直そうとすると、マイクロソフトみたいな誤魔化しを
やらなければならなくなる。
まず、マイクロカーネルのバージョン（Windows NTにあたる）を開発する。
とりあえずカーネルモード、ユーザモードに処理を振り分けて、
極力ユーザモードで処理してしまうようにする。
次にカーネルとドライバとHAL（ハードウェアを抽象化する層）を
カーネルから分離した状態にして切り分ける。
最終的にドライバのインタフェースを標準化して、正式なドライバのみを
認定していく。
この作業を今からOSSでやるとすると、どれくらいのリソースが
掛かるのか？という話なんだが？
0099login:Penguin
2012/03/22(木) 01:02:17.08ID:Gq7eum/2「俺が、俺が」ばっかりのOSS界隈に居るのか疑問。
0100login:Penguin
2012/03/22(木) 01:06:32.09ID:O+AuMM3k自分でバカ発言する
のかね
0101login:Penguin
2012/03/22(木) 01:14:04.05ID:Gq7eum/2■ このスレッドは過去ログ倉庫に格納されています