元スレ【Linux】カーネル総合6【Kernel】

kernel覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

856 :

http://git.kernel.org/linus/ad81f0545ef01ea651886dddac4bef6cec930092

860 :

>>857
3.11って縁起悪いな
欠番にしろ

862 :

災害が起こった日付と年代を過去に遡って欠番にしよう(提案)

863 :

そんなことしたらどれも使えない
番号やめてアルファベットにでもしとけ

865 :

13は縁起が悪いから14からで

866 :

>>812
モジュールって言ってもコードが着脱出来るだけで、動作時はくっついてモノリシックじゃん

868 :

結局のところファイルシステムとかデバイスドライバーがカーネル内部のシステムコールを通してユーザープロセスと通信するとマイクロカーネルなんかね？
メリットはFSやデバイスドライバーがカーネル本体をこわせないってことだけど、
その引きかえにデメリットとしてオーバーヘッドがでかいってことか
FSやデバイスドライバーが自滅すればシステムとして動作不能になって復旧できないんだからマイクロカーネルにするメリット自体存在しないと言うことになってしまうね。

869 :

建前としては、別の仮想アドレス空間で実行してる奴だったら落ちても
再起動すりゃいいだろって考えなんだけど、そううまくは行かないって話

871 :

カーネル本体を壊せないというのだけが条件なら別のアドレス空間を使う以外にも方法があるけど、
そういうのはマイクロカーネルとは言わないみたいだな。

872 :

最近のwindowsはビデオドライバがエラー落ちしても何事もなかったかのように復帰する
(ブルースクリーンになったりせず、ドライバを再起動したという通知が出るだけ。
人によってはトラブルが起きていたことすら気がつかないレベル)けど、ああいうのがすべての
ドライバでできるのがマイクロカーネルの理想なんでないの?
あれはあれですごいと思う。

873 :

アレっ？落ちてる？

875 :

毎晩>>874を復唱したいですね。

877 :

>>872
それはマイクロカーネルだから、ではないでしょ

881 :

>>879
それは無い、絶対に無い
http://cpplover.blogspot.jp/2013/04/llvmclanglinuxgcc.html
gccの堕落っぷりと、それに汚染されているLinuxカーネル
美学を失ったらおしまいよ
こういう状況を憂いてのLLVMLinux

882 :

Linuxカーネルのような低レベルなソフトウェアは、
コンパイラに依存するしか無い(標準Cの範囲内では書けない)から、
拡張機能を使用することにそれほど躊躇する必要はないんじゃないかな。
GCC一択の状況が変わればトレードオフのバランスも変わるだろうけど。

883 :

便利であれば何でもありとばかりに実装された頭悪い独自拡張と
それをうれしそうに使うバカプログラマどもは害悪だな

884 :

だったらアセンブラ使うか
ってことになるだけのような

885 = 881 :

そういう事じゃないよ
美しく在るべきである
汚染は早期に排除すべき

887 = 881 :

>LinuxカーネルはGCCでコンパイルできるように書かれていて、
これが美しくないんだよ
>便利であれば何でもありとばかりに実装された頭悪い独自拡張
によって汚染されてる
「便利であれば」ではなく「便利そうだと思えたら」だ
実は全然必要ない事はLLVMLinuxが実証している

890 = 882 :

ISO-CでLinuxカーネルを書けると思ってるの?
特定の処理系を指定せざるをえないんだよ。
clangをサポートするという判断も当然ありえるけど、
ただのトレードオフでしかないよ。

そうなったとしても、今度はVisual-Cでクロスコンパイルできないと
美しくないとか言い出す人がいるかもね。
そんな「美しい」かどうかを判断基準にしている人を相手にすべきと思う?

891 = 883 :

＞特定の処理系を指定せざるをえないんだよ。

アセンブラコード喰わせたりアライメント指定したりとか
そーゆー「あるある」依存以外のところを具体的にどうぞ

892 = 882 :

「あるある」を除くのかねw その質問に何の意味があるの?
答えられないトンチ問題でやりこめた俺かっこいいってだけじゃないの?

じゃあ、上に書いたvolatileバグの件は?
GCCがおかしいと言う意見が多かったけど、ISO-Cで決まってません。

896 = 895 :

x86しか吐けないiccなど問題ではない
ARMやSPARCやPOWERやMIPSや、ありとあらゆるCPUに対応するのが
Linuxカーネルの使命
全てのコンパイラでビルドが通るのもLinuxカーネルの使命と思うよ

897 = 895 :

マイクロソフトが商売にならないと切り捨てた全てを救済するのがLinuxの使命
Ｌｉｎｕｘの存在意義

898 = 895 :

現実にLinuxはARMをメジャーに引き上げた
Windowsでは日の目を見なかったろうCPUをメジャーなCPUにした
Windowsは慌てて後追い

899 :

別にclangでコンパイルできるようになっても構わないけど、
「べき」とか思わない。ARMその他でも現状動いているじゃん。
gcc汚染とも思わない。C99に汚染されている、C89でコンパイル
できるべきとか言わないのと同じ。

clang側は、将来に渡ってLinuxカーネルコンパイルをサポートする
つもりはあるのかね?

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / kernel一覧へ

類似してるかもしれないスレッド

• 【Linux】カーネル総合7【Kernel】 (247) - [97%] - 2022/12/17 20:30
• 【Linux】カーネル総合5【Kernel】 (1001) - [97%] - 2011/5/28 4:48
• 【Linux】カーネル総合3【Kernel】 (984) - [97%] - 2008/1/18 7:47 ○
• 【Linux】カーネル総合４【Kernel】 (1001) - [93%] - 2009/9/21 1:16 ○
• SGI KDBを使ったカーネルデバッグスレ (383) - [25%] - 2021/1/11 2:15