Linux 2.6.19 out! 40
ストーリー by kazekiri
二ヶ月ちょいか 部門より
二ヶ月ちょいか 部門より
2.6.19がリリースされてます。ミラーを待ちましょう。
しかし、2.6.19からPATAがlibataに変更されてるらしいので、PATAのデバイスファイル名が/dev/hd[abcd]から/dev/sd[abcd]になってるとの噂。確認は各自がんがれ。
2.6.19がリリースされてます。ミラーを待ちましょう。
しかし、2.6.19からPATAがlibataに変更されてるらしいので、PATAのデバイスファイル名が/dev/hd[abcd]から/dev/sd[abcd]になってるとの噂。確認は各自がんがれ。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
デバイスファイル名 (スコア:3, 参考になる)
SCSIデバイスは基本的に認識された順に名前が付けられていくため、SCSIデバイスが他にもあるとIDEは必ずしもsda-sddにはならないと思います。
でも安心してください、そういう状況でも特定のデバイスに特定の名前を与える為にudevがあるのです。
# ちなみにプロセッサが沢山あるとブートペンギンが増えます
(OT)udevって、いいのかな?(´・ω・`)(Re:デバイスファイル名) (スコア:1)
例えばHDDを増設する場合、中身の型番かバスでインタフェース番号(sd[a-z]/hd[a-z]のa-zの部分)を決定する必要があるんですが、バス番号で決定してしまうと差し間違ったときに問題がありますし、デバイス名だと重複したときに事実上ランダムに番号がアサインされたり入れ換えたドライブが別種だとudevの設定を書き直さないといけないので…
…バスとデバイス名の組合せで上手く書く方法がわからないです(涙)
今までのIDEのドライバ(hd*の方)はObsoleteっぽいですし、PATAとSATAのドライバがlibataに統括されるとインストールやアップグレードもややこしくなるでしょうから…(;´Д`)
Re:デバイスファイル名 (スコア:0)
結局はSolarisやIRIXみたくc?t?d?とかdks?d?とかのやり方がよかったんじゃね?
Re:デバイスファイル名 (スコア:1, 興味深い)
見たことあるので間違いない
Re:デバイスファイル名 (スコア:1)
Re:デバイスファイル名 (スコア:0)
# というわけで2.6.19にしたDebian/Sargeで書いてるとこ
個人的にはAC97の省電力が嬉しいです。
Re:デバイスファイル名 (スコア:0)
> そういう状況でも特定のデバイスに特定の名前を与える為にudevがあるのです
ちょっと語弊があるようなのでコメント.
名前を付けるのはカーネルです.
udevはカーネルが付けた名前に対するデバイスノードを作成するものです.
# カーネルが付けた名前と違う名前のデバイスノードも作れますが
ドライバ書いてる人や使ってる人にTIPS (スコア:2, 参考になる)
#include <linux/config.h>
を使っていましたが、とうとう廃止になりました。
代わりのファイルは、linux/autoconf.hになっています。
(と言うか、2.6.18以前で既にlinux/config.hはlinux/autoconf.hを読むだけのダミーファイルになっていましたが…)
ドライバのコンパイルが通らない場合なんかは、
#include <linux/config.h> → #include <linux/autoconf.h> してみてどうか試してみたらどうかと思いますので…
リリース日は? (スコア:1, すばらしい洞察)
Re:リリース日は? (スコア:2, 参考になる)
だそうです。
なんでもかんでもSCSIエミュにするなら (スコア:1, すばらしい洞察)
Re:なんでもかんでもSCSIエミュにするなら (スコア:2, おもしろおかしい)
/dev/D
・
・
・
Re:なんでもかんでもSCSIエミュにするなら (スコア:0)
シェルから見えないだけで、WindowsでもUSBデバイスやディスプレイは全部デバイスファイルにマップされてる。
- \\.\A:
- \\.\PHYSICALDRIVE1
- \\.\TAPE1
- \\.\SCSI2
マジレスすまそ。Re:なんでもかんでもSCSIエミュにするなら (スコア:1)
問題なのはアプリケーションで対応していない物や「想定内」のデバイス名を前提にしている場合がかなりある事ではないですかね…FHSがまとまったのだから、udevでの名前付けの規格が早く決らないものか。と思うのですが。
Re:なんでもかんでもSCSIエミュにするなら (スコア:0)
とでも考えればよいのでは?
もともと抽象度はATAPIより高いのだから
「SCSIの具体的HW」のことは忘れて「SCSIというデバイス接続概念」
だと思っとけば、まだまだ新しいことを考える必要もないかと。
へー (スコア:0)
SCSI持ってないのに (スコア:0)
仮想ファイルシステムのVFSのように、ストレージデバイスもそんな仕組みにしちゃえばいいのかな?
エンタープライズではまだSCSIは現役だけど、そのうちTTYみたいに実体が別の物に入れ替わってしまうのかも。
Re:SCSI持ってないのに (スコア:1)
ATA(IDE)は元々HDD用の規格でしたが、CD-ROM等その他のデバイスを接続する必要ができた時、
まんどくさいのでSCSIプロトコルをラップしてそのまま使うことにしました。
これがATAPI(ATA Packet Interface)です。
デバイス側はラップ(包み)を解く簡単な前処理をつけるだけでSCSI用を流用でき、またOS側も既存のSCSI用ドライバをそのまま流用できる利点があります。
誤解を恐れずいえば、ATAPIはHDDのみ特別扱いするSCSIといってもいいでしょう。
USB、IEEE1394(FireWire)、ファイバーチャネルも同様で、上位層ではSCSIプロトコルが使われています。
これらは様々なデバイスを接続できるようにデバイス毎に別の上位層プロトコルを使えますが、マスストレージデバイスで一般的に使われているのはSCSIです。USBとFireWire両対応のデバイスが安価に売られているのは、上位層を共用できるためです。
つうわけでSCSI(インターフェイス)を使っていなくても、実はSCSI(プロトコル)使ってると思います。
Re:SCSI持ってないのに (スコア:0)
Linux カーネルって… (スコア:0)
今回リリースされたのは Linux カーネル だと思うのですが、これは単体でインストールして使用できるものなのでしょうか?
それとも、何らかのディストリビューションと組み合わせて使うもんなんでしょうか?
# くだらない質問で申し訳ありませんがご容赦下さい
# 勿論AC
ひどい目にあった(Re:Linux カーネルって…) (スコア:2, 参考になる)
それまでは(自分のマシンとかで)カーネルをコンパイルしていました。
同じくVMWareのマシンでそれをやったら、アウト。原因は、
VMWareのドライブがカーネルのバージョンをみて、そのカーネルの
ドライバのディレクトリめがけてvmnetのドライバを入れてくる。
RedHatやSuseの「一昔前の」バージョンを参照するため、
自分でコンパイルしたカーネルなんぞ問題外。泣く泣くRedHatを9から
7.3へ戻した記憶があります。ディストリ謹製のカーネルがいいんじゃないかな?
-- gonta --
"May Macintosh be with you"
Re:ひどい目にあった(Re:Linux カーネルって…) (スコア:1)
Re:ひどい目にあった(Re:Linux カーネルって…) (スコア:0)
それは入れ方が悪いだけかと。
/usr/src以下にソースを展開しておけば、vmwareの設定スクリプトが適宜ドライバをコンパイルするはず。
Re:ひどい目にあった(Re:Linux カーネルって…) (スコア:0)
VMwareは全然関係なくて,単にカーネルを再構築するスキルが足りないだけ.
だれだ,「参考になる」なんてモデレートしたやつは.
> 自分でコンパイルしたカーネルなんぞ問題外
VMwareと一緒にインストールされる vmware-config.pl を実行するだけで
vmnetは再コンパイルできる.コンパイル出来なかった場合は原因をエラーとして表示してくれる.
Re:Linux カーネルって… (スコア:1)
今はできないのかな?
Fedora の場合は make rpm-pkg や make binrpm-pkg で rpm 作れますよ。
もっと良い方法がありそうだけど。
みんなはどうしてるの?
Re:Linux カーネルって… (スコア:0)
mkkpkg:
make new configured kernel package from kernel SRPM.
Re:Linux カーネルって… (スコア:0)
まあ確かに、こういう人っているんだなあ位の意味には「興味深い」かな。
Re:Linux カーネルって… (スコア:1, 興味深い)
思い立ったが吉日 (スコア:0)
Re:Linux カーネルって…(オフトピで) (スコア:0)
IDだのACだの関係なく、ここは底辺だけが広がり続ける
サイトだってことを認めようよ。
Re:まじれす (スコア:0)
理屈上は大抵のディストロで、既存のカーネルとすげかえようとすればできるはず。
でも本記事のソースはパッケージ化してないので(一個のファイルにまとめているだけ)、パッケージシステムにとっては異物混入に近い。
こういう水遊びはSlack/Plamoなどが面白い。
# glibcの火遊びに挑戦したことがないorzな臆病者
Re:まじれす (スコア:2, 参考になる)
元コメント [srad.jp]氏の環境は Fedora [fedora.jp] とか Vine [vinelinux.org] だ、ということですから「自分で spec 書いて rpm 作れば周りのパッケージと適合するよ」という話になるのではないかと。
# それが面倒なら Slackware [slackware.com] か Plamo [linet.gr.jp] 辺りを使ってろ、というのは御意なのですが。
Re:まじれす (スコア:0)
皆様、くだらない質問に回答していただきありがとうございました。
今後暇があったらカーネルの入れ替えなどを試してみようかと思います。
# 勿論実験用の環境で…。
ディストリのパッケージ管理システムのサポート対象期間であれば、基本的にはそちらでカーネルのアップグレードをしたほうがよさげですね。
Re:まじれす (スコア:1)
長年惰性でSlackwareを使い続け、某機能が必然な為に、10.1のと或る時期からlinuxの2.6系に移行しました。2.6.x.yは無視で、2.6.xの度に更新していましたが、今まで外れは無いです。
でこれも惰性で2.2系以来USAGI [linux-ipv6.org] SNAPを充て続けて来たのですが、ここ数箇月更新が無く2.6.17用止まりなのが気がかりです。Slackware 11.0に更新した今もlinuxは2.6.17のままですが、そろそろUSAGIは止めてlinux更新かなと考えています。
結局 (スコア:0)
ダメもとで環境破壊しながら勉強するのも悪くは無いでしょうけど。VMware とかも使えるのだし。
Re:結局 (スコア:0)
一定の手順はありますから、少し慣れればそう難しくはないと思います。
Linux Kernel Watch (スコア:0)
ttp://www.atmarkit.co.jp/flinux/rensai/watch2006/watch11a.html