ディバイスドライバを ..
[2ch|▼Menu]
261:linuxer
03/07/09 01:17 W4/RwfEH
僕はLinux のethernet のドライバを改造したいデス
ふつは通信用途に最適化されてると効きました
それはぺケットをみる目的につかいます
なにかアイディアはありますか??

262:login:Penguin
03/07/09 01:22 9Ead9bym
tcpdump等の既存のものより詳細にみれなければ意味がない気がするけど大丈
夫なのかしら。


263:_
03/07/09 01:29 RRaEUYou
URLリンク(homepage.mac.com)

264:login:Penguin
03/07/09 01:48 FD/eKW7A
>>262
石にもよるでしょうねえ。
最近の利口な奴はいろいろ手を入れてくれるし。


265:login:Penguin
03/07/09 13:47 GtKhiIZ8
>>261
現行ドライバだと、どの点が不満なのか言ってもらわないと助言しようがないよ
パケットモニタリングはNICチップのpromiscuousモードの仕様に依存する話だ

266:login:Penguin
03/07/10 07:33 sMbuqqa1
>>265
現行のドライバならpromiscuousモードで動かしたときに
パフォーマンスがわるいな感じです
それでぺケットを取りこぼすことになってしまうので
キャプチャ用途に最適化できたらいいなと考えましたです

267:login:Penguin
03/07/10 07:41 oOmBMqv3
>>266
promiscuousモードだと全パケットをホストPCに転送するから
通常モードに比べて取りこぼす可能性は増える。対象のNICチップは何?
素直にintelなり3comを買えば済むだけの話かもよ。

ちなみにリアルテック(蟹)の性能がよくないのは特許を避けてるから。
現状でいいパフォーマンスのNICが欲しけりゃIntel(or元DEC)、3comの
ちょっと値が張るNICを買うしかないよ。

ドライバでどうこうできる話ではない

268:login:Penguin
03/07/10 23:13 TravPTn9
>>267
リアルテクです。3COMも使ってますが、スイッチと相性が悪いな感じで
無反応になってしまう(壊れているのかもしれない)こともありますで
リアルテクでペルフォマンスがよくならないかなと想いました
ちなみに特許って具体的にはどんな特許ですか?

269:login:Penguin
03/07/10 23:46 bBVT4pXs
>>268
261と268で目的が変化してるぞ。

270:login:Penguin
03/07/11 13:32 CtoBVZIQ
>>268
そもそもパケットモニタリングするのにスイッチングハブを使ってる時点でアウト
リピータハブ(ダムハプ)を使わないと他ホストの通信は傍受できないよ

結論
・RealtekのNICは捨てて、Intelか3Comを使え
・スイッチングハブではなく、リピータハブを使え

全然デバドラと関係ないや スレ違いどころか板違い?

271:login:Penguin
03/07/13 22:55 UrPfG9sV
>>267
>promiscuousモードだと全パケットをホストPCに転送するから
違うよ。promiscuousモードって言うのは、リンク層で受信したデータが
自ホストの物理アドレスでなくても受信すること。
>>270が正しい事を言っている。

272:login:Penguin
03/07/14 02:37 imGWjqw6
age

273:267=270
03/07/14 15:12 E/Ns9e+C
>>271
すまん 267=270 なのだが 何か矛盾したこと言ったかな?

MAC層(データリンク層)の処理はNICチップで行われる。
ホストPCはMAC層の処理にはまったく関与しない。
MAC層の処理後、必要なデータだけPCIバスを介してホストPCにDMA転送する。

つまり、通常モードだと自ホスト宛かブロードキャストのパケットデータだけを
ホストPCに転送すればいいのに対し、promiscuousモードだとすべての
パケットデータを転送しなくてはならず、転送量が膨大になる。
そのため、バッファがあふれる(=データを取りこぼす)ことになりやすい。

274:268
03/07/15 03:30 Yac3cQfq
スイッチはL3スイッチでポトミラリング機能がありますよ

ただ3COMのNICでも限界があるとですがぎりぎりまでぺケットの
モニタ用に最適化したいと思いましたです
リアルテクの話は忘れてください ふつはバッファも通信用に
チュニングすれて確保してると思ったけどぺケットをモニタするときは
受け取るだけだから ドライバで受信用のバッファを多めに
できたらいいなと思ったよ でもどうやったらいいか分らないよ
ヘルプしてください





275:山崎 渉
03/07/15 11:17 2JhhXBQM

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

276:login:Penguin
03/07/15 12:07 Fo16Kpwc
(・∀・)renice!

277:login:Penguin
03/07/22 11:30 6WQ9WMDa
(・∀・)renice!

278:login:Penguin
03/07/25 12:52 NH3LXVfX
(・∀・)renice!

279:login:Penguin
03/07/30 12:07 cPdgkLk2
(・∀・)renice!

280:ぼるじょあ ◆yBEncckFOU
03/08/02 05:04 GfRe8vK7
     ∧_∧  ∧_∧
ピュ.ー (  ・3・) (  ^^ ) <これからも僕たちを応援して下さいね(^^)。
  =〔~∪ ̄ ̄ ̄∪ ̄ ̄〕
  = ◎―――◎                      山崎渉&ぼるじょあ

281:login:Penguin
03/08/02 10:27 2rmp9gin
(・∀・)renice!

282:login:Penguin
03/08/08 11:54 mg5o8ebS
(・∀・)renice!

283:login:Penguin
03/08/13 12:30 pfCYHBFY
(・∀・)renice!

284:login:Penguin
03/08/14 22:31 EZZe4dzO
$> cd /pub
$> more beer


285:login:Penguin
03/08/14 22:44 EZZe4dzO
$> man woman
$> Segmentaion fault (core dumped)


286:山崎 渉
03/08/15 22:51 dil3w4kp
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

287:login:Penguin
03/08/15 23:47 GfNK1qbf
(・∀・)renice!

288:login:Penguin
03/08/16 15:04 rNtMNMvg
(・∀・)renice!

289:login:Penguin
03/08/25 09:46 +hXUD3jL
(・∀・)renice!

290:login:Penguin
03/09/02 21:16 1mo12GKS
insmod xxx.oってことはドライバのソースはどんなに大きくてもxxx.cの1っこだけじゃないとだめなの?

291:login:Penguin
03/09/02 21:20 88sqYoXe
>>1は、ママンでもファックしてろや!hahahahahahaaaaaaaaaaaaaa!

292:login:Penguin
03/09/02 22:18 qo69XMHR
>>290
完全なるカーネルモジュールにヘッダやリンカはいらない。
ソースは常にひとつ。

293:login:Penguin
03/09/03 08:04 CuYcG2U3
>>290
Cファイルをインクルードすればいいだろ。

294:login:Penguin
03/09/03 11:30 4cm8kGPF
>>293
よりによって一番最悪な答えですね先生

295:login:Penguin
03/09/03 16:47 iWz7WMbL
>>290
info ld
-rの説明読め。


296:login:Penguin
04/01/07 22:36 ui3n7e6w
だいぶ下がってますが、
2.6 と 2.4 のドライバ記述って何か変りました?
2.6 まだインストしてないので報告キボンヌ・・・
2.2 -> 2.4 程は変ってないのかなー?

297:login:Penguin
04/01/16 18:02 ZUOtu/O9
PCIのデバイスドライバを作成していますが、
全くできません。
less /proc/iomemで書かれているアドレスで
read、write関数を使って書いたり、読んだりしてもだめです。
何がいけないんでしょうか?


298:login:Penguin
04/01/16 19:15 JS8EwlnL
とりあえず、lspci -vvv を晒してみたらどうでしょう。
もちろんデバイス指定でね。
それを見て私が答えられるかどうかはまた別の話ですけど。


299:login:Penguin
04/01/16 19:52 ZUOtu/O9
lspci -vvvで次のような表示になりました。
00:11.0 Class ff00: Altera Corporation: Unknown device 1998 (rev 07)
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 16
Region 0: Memory at dffe0000 (32-bit, non-prefetchable) [size=64K]

300:298
04/01/16 20:57 JS8EwlnL
FPGAですね。

私もそんなに知っているわけではないので、
あまりあてにはしないで欲しいのですけれど…
lspciの結果は特に変なところは無いと思います。
Class ff00はどのクラスにも属さないと言うことだと思うのでちょっと気にはなりますが、
読み書きぐらいはできるでしょうね、きっと。

だとすると、あとはドライバのソースでチョンボがあるか
FPGAの中で書きこみ禁止になっているとかですかね。
FPGAにどんなipが載っているのか分からないので、あくまで推測ですけど。

あんまり力になれなくてごめんね。


301:login:Penguin
04/01/18 02:27 +zT3hNOG
>>298
read/writeのかわりに
ioremap_nocache()で対象アドレスのページを取得して、
ポインタで直接参照してみたら?

よみたい物理アドレスが
(unsigned int) p_adr
だとしたら

unsigned char p_read(unsigned int p_adr){
unsigned int v_page,v_offset;
unsigned char ret;
v_offset=p_adr&0x0fff;
v_page=ioremap_nocache(p_adr&0xfffff000, 0x1000);
ret=*((unsigned char *)(v_page + v_offset));
iounmap(v_page);
return (ret);
}

適当だけどこんな感じで。ページサイズが4K決め打ちだけど。

302:login:Penguin
04/01/18 02:28 +zT3hNOG
>>299のマチガイだ。

303:login:Penguin
04/01/19 07:32 kPFQP2Tn
PCIバスアナライザで観測しながらアクセスしてみそ

304:login:Penguin
04/01/22 14:27 O8v9hJ5s
>>303

持っているならいい方法だけどね。
買おうとすると激しく高い。
レンタルでも中古でも激しく高い。

でも、欲しいね。

305:login:Penguin
04/01/28 10:42 N5b+GE5n
マジレスすれば
ロジアナでPCIバスを観測するか、PCIバスアナライザを使うか
どっちかしないと、PCIデバイス/ドライバの開発は無理だろう

306:login:Penguin
04/01/28 12:46 OnT2yC/X
んなこたーない!
297 が FPGA開発を同時にやってるならまだしも・・・
あったほうが楽なのは確かだが、無理ではない。

ハード屋さんはバスレベルで確認して提出するはず。
read/write 出来ないのはドライバの不具合。

>>297 は pci_find_device 関数など、基本から勉強したほうがよさそう。

307:305
04/01/28 15:27 N5b+GE5n
無理ではないって言っても、そんなマゾプレイみたいなコトしたくないよ
目隠しして半田付けしろっていうのに近いな

PCIのロジックって複雑だから、実機でバグが露呈するのはよくあること
430FXで動いたからって 875Pでは動かないとか余裕であるよ
市場に流通してるチップセットすべてで確認しないと市販は無理

名の通った枯れてるチップならまだしも、実機の動作チェックもしてない
FPGAの回路をつかったPCIカードなら、最初から疑ってかからなきゃダメだと思います

> ハード屋さんはバスレベルで確認して提出するはず。

PCIバスの全パターンをシミュレーションできる検証ツールってすごく高いよ
特にFPGAの開発のために検証環境買うのはコストにあわない
PCIバスアナライザがある環境で実機試験して、少しずつ直すほうが早くて安い

308:login:Penguin
04/01/28 18:36 XM3JMqvR
>>307
そーゆーのはハード屋さんの仕事じゃないかと。
PCIブリッジの違いで動かないなんてのは設定云々じゃない限りドライバじゃ直せん。


309:login:Penguin
04/01/28 19:09 ceOaOw14
> そーゆーのはハード屋さんの仕事じゃないかと。

おれもそう思う。
でも、実際はソフト組み込んだらなんかおかしくて、
実は結局、微妙にハードが悪かったなんて事は良くある話だね。
きっと >>305 は苦い思いをしたんだろうよ。

310:login:Penguin
04/01/29 18:47 ci1wDtTm
>実は結局、微妙にハードが悪かったなんて事は良くある話だね。
ハード絡みやってりゃ必ずあるね。
慣れてくればハード、ソフトどっちが悪いか何となくわかるようになるけど。
制御チップ動かす時なんかはオシロ、ロジアナの出番が増える。

さすがに PCI制御用FPGAまで計測器突っ込んだ亊はないけどね・・・
そこまで行くと スレ違いですね >> 307

311:307
04/01/30 07:19 tIkj6Ynv
私はPWBAからASIC/FPGA デバイスドライバ アプリ まで全部自分で開発する
ある意味何でも屋です

FPGAの検証を実機でやるときにデバイスドライバを作ってるはずだから
バスレベルで動作検証済なら、そのとき使ったドライバをハード屋さんから
もらってくればいいんだと思います

もちろんLinuxじゃない別のOSで検証してる場合もあるだろうけど
今の時代はLinuxでやってるケースがほとんどではないかなぁ

Linuxは
1. ソースが公開されてて、ドキュメントも多くドライバ書くのが楽
2. CDからブートしてRAMDISKだけで動くシステムを簡単に作れる

等の利点があって、特に2が重要
PCIバスのハードのデバッグだとしばしばフリーズするので
正しくshutdownしないままリセットすることが頻発する。
winだろうがlinuxだろうがHDDにOSが入ってるシステムだと、
リセット連発していると、次の起動時に時間がかかるし
そのうちHDDの内容が不整合を起こしてくる。
1CD ramdiskオンリー システムだと、気軽にリセットできて楽なんだ。
まぁlinuxじゃなくてFreeBSDでもいいんだけど。

私は5〜6年くらい前はFreeBSD(2.x/3.xの時代)でPCIカードのハードのデバグ
やってたけど、今世紀に入ってからLinux(2.2の頃から)でやるようになった。
時代の流れで、商品としてlinuxへの対応が必要ってことになったので
最初からlinux用のドライバ書いておけば後が楽になるからね。

スレ違いだったかな
駄文失礼

312:login:Penguin
04/02/03 23:12 j9rA+N1w
>駄文失礼

気にしなくていいぜ。(w

313:login:Penguin
04/02/09 07:11 7h6uvjnn
すいません、どうしようもない質問なんですが、
実験的にカーネルパニックを発生させるドライバを作るのには
どうすればよいでしょうか?
カーネル関数panic()を使っても
ハングするだけでパニックしないんです。。。
どうか教えてください。

314:login:Penguin
04/02/09 20:13 oe9mNV77
このスレは俺に勇気をくれた。

315:login:Penguin
04/02/10 00:02 0xm4A1oM
>>313
コンソールに"Kernel panic: …"って出てないの?


316:login:Penguin
04/02/10 00:52 4iNUE3rF
>>313->panic();


317:login:Penguin
04/02/10 21:13 WwFCucZO
>>315−316
返信ありがとうございます!
単純にパニックするよりoops画面が表示するようにしたいのです。
mmapあたりをいじくるドライバを作れば、
oops画面を表示させることは可能ですか?

318:殴られそうだが
04/02/10 23:35 0xm4A1oM
>>317
試してないけど、
*(unsigned long)0 = 0;
とか。


319:login:Penguin
04/02/11 00:21 QfDGoor4
>>318
似たようなので、
x=0;
x=x/x;
ってのをやってみたのですがダメですた。
やっぱLinuxって頑強だと思いますた。
mmapも見てみたらカーネル空間でなく補助記憶空間に
マップするだけのようですし・・・
アドレス例外でoopsできるような方法とかあるのですかね??

320:login:Penguin
04/02/11 17:17 ViS2X9Xm
Oopsとpanicを混同しているような気がしないでもない。


321:login:Penguin
04/02/12 00:21 9Bh5Rhh+
>>320
すみません。。。
パニックとシステムフォルト(oops)と勘違いしていたようです。。。
ドライバからシステムフォルト(oops)
させるような方法ってあるのでしょうか?

322:login:Penguin
04/02/14 07:34 kX0ZpYOB
linuxはsolarisみたいにクラッシュダンプ取れますか??

323:login:Penguin
04/02/16 00:01 dUYGf/LZ
>>322
URLリンク(lkcd.sourceforge.net)


324:login:Penguin
04/02/19 02:35 tYIYueC9
Linuxでのデバイス・ノード管理は現在
従来の/dev以下のデバイス・ノードファイル、devfs、udevが
存在しているようですが、デバイスドライバを書くような
デバドラ開発者にはこの状態は影響するのでしょうか?


325:login:Penguin
04/02/19 10:34 iwEBqmwA
私は従来の/dev以下のデバイス・ノードファイルを使ってます
devfsに対応するのも簡単だけど優先度低いから先送り

326:login:Penguin
04/02/24 22:37 BGHqYIMS
modpostについて詳しく解説している文書をご存知でしたら教えて下さい。

327:login:Penguin
04/03/17 23:57 P4QfZyWd
データシートをどうやって手に入れるか
それが問題だ

328:login:Penguin
04/03/18 10:56 WBeyRceU
何のデータシート?

329:login:Penguin
04/04/08 16:25 E32BiKCa
mmapについて質問させてください。

メモリデバイスをmmapするとき、ページサイズを4096Byteとした場合、
mmapされたデバイスの先頭からの"物理アドレス"と
mmapしたプロセスのデバイスに割り当てられた"仮想アドレス"の
下位12bit(2^12 = 4096)は一致するのでしょうか?

mmapではプロセスの仮想空間にページサイズ単位で
ファイルやデバイスを割り当てることが出来るわけですよね。
ページサイズが関係してくると言うことはMMUのようなものが
作用して、この割り当てを管理しているのですよね。
(あるいはMMUそのものなんですか?そこが分かってないのですが)

もしも、MMUの管理下にあるならば、実空間と仮想空間のアドレスの
下位12bitは一致するはずです。
MMUはページサイズ以下のアドレスを知らないはずですから。
ここまでは私の理解に間違えはないですよね。

でも、mmapが実際にどんな風に動いているか良く分からないので、
上のような疑問が沸いてしまったのです。
どなたかお分かりいになる方がいましたら教えてください。



330:login:Penguin
04/04/08 17:57 /VjqMrH1
>>329
つ[ mmap.c ]

331:login:Penguin
04/04/09 00:53 E9wQ2At3
いいなこのスレ

332:login:Penguin
04/04/09 00:58 ImS0ZAox
>>330
ha?

333:login:Penguin
04/04/09 00:59 ImS0ZAox
あぁソース嫁ってことかw


334:login:Penguin
04/04/09 14:52 8RpqlllW
>>329
CPU/MMUアーキテクチャに依存する話だね。
IA32に限っていえばその理解でいいと思うよ。
他archでもまずそうなってるだろう。
そうなってないMMUなんて見たことない。


335:login:Penguin
04/04/09 15:39 dsP5+/oo
2次キャッシュを UBS mem に格納して使いたし。可能?

336:login:Penguin
04/04/09 21:34 /keZpBhh
>>335
CPUの2次キャッシュをUSBメモリにやらせるってこと?

337:login:Penguin
04/04/10 01:41 04yJkWho
AGE

338:login:Penguin
04/04/13 23:49 bzoEXS/o
USBのデバイスドライバ作る時のTIPSを教えてください

339:login:Penguin
04/04/14 15:26 XimV19c+
デバイスを破壊出来るデバイスドライバーの作り方教えてください

340:login:Penguin
04/04/14 23:18 QKI6oVKA
>>339
1.どこからかゴルフのドライバーを手に入れる。
2.ドライバーのフェイスにデバイスを貼り付ける(ガムテープでも可)

しかる後にドライバーを振りかぶり、路面、ブロック塀etc.にぶつけること。

341:login:Penguin
04/04/15 10:49 D/fT1Zhi
>>340
( ´д)ヒソ(´д`)ヒソ(д` )

342:login:Penguin
04/04/19 20:10 TjHP8JDs
>>340
( ´д)チョメ(´д`)チョメ(д` )


343:login:Penguin
04/04/27 21:12 ftQXOuAJ
v2.6.x 用の module (.ko) の作り方ってどっかに落ちてませんか?
v2.4.x だと gcc -c するだけで insmod できるイメージができましたが、
v2.6.x だとなんか後工程があるんですよね?

344:login:Penguin
04/04/27 21:18 VEIU93yI
>>339
FDDにアクセスして、その音で音楽を鳴らす。
CDDのトレイを頻繁に出し入れする。
ってトレイは入れられたっけ?

345:login:Penguin
04/04/28 09:36 r7A4ZD5z
>>344
出し入れ可能だけど、作り方は教えられないのでは?
もう既に完成してしまっているし ソース嫁としか言えないと思う

346:login:Penguin
04/04/29 22:03 ugZV/Avt
>>344
CDDのトレイを開け閉めする位ならioctlで……

347:login:Penguin
04/05/05 09:59 IcDQ6/Fz
v2.4でUSBキーボードドライバにRAWレベルアクセスする方法知りませんか?
usb/usbkbd.cを単品でモジュール化してみたけど、プログラムからのアクセス
方法がわからない・・・
usb_register時にマイナーバージョンの情報を登録してないみたいだけど
デバイスファイルでアクセスしようと思うと無理なのかな〜・・・

348:login:Penguin
04/07/17 17:55 z93SFsgN
落ちそう・・・見込みなさそうだけど上げ

349:login:Penguin
04/07/18 17:33 qhsm/Ia2
>>343
URLリンク(linuxdevices.com)とか
URLリンク(lwn.net)とかではどう?

350:login:Penguin
04/07/27 03:02 AwmCdxXP


Moz2chで見てると
レスがだんだん右にずれていくます。



351:login:Penguin
04/07/27 03:08 AwmCdxXP

USBに2台のWebカメラをつなげてまちゅが

May 30 08:31:05 localhost kernel: usb-uhci.c: interrupt,status 3, frame# 1728

しばらく動いた後に/var/log/messageに出力されてカメラがハングしてちまいます。
USBのデバイスドライバは何を言ったのでしょうか?おちえてください。



352:login:Penguin
04/07/27 03:23 7ve9Hskt
>>351
要はエラーが起きたのですね。それ以上あまり解析のタシにはなりません。
status 3 ってのは、割り込みが起きて、IOC と Error が立っていたんです。
# IOCの方は、割り込みを発生する機能なので、エラーじゃないですが。


353:login:Penguin
04/08/02 14:39 QD1yhPkc
チップセットのドライバって具体的にはどんなことやってるの?

354:login:Penguin
04/08/02 16:42 4u8OC/CN
すごく恥かしいあんなことやこんなこと

355:login:Penguin
04/08/02 17:48 Wbtl3uph
>>354
激しく気になります。

356:login:Penguin
04/08/03 23:29 HnnAhZGX
突然ですが、デバドラのioctlからpollやselectって呼べるかどなたか知ってますか?
pollやselectの引数の構造体に何を入れていいのかわかりません。

357:login:Penguin
04/08/03 23:47 0P3Qaw2+
>>356
ioctlのハンドラからsys_selectとか呼びたいって事ですか?
呼べないことはないと思うけど…

なんでそんな変な事をする必要があるのか興味がありますな。
引数は普通にselectに食わせているものを同じように渡せば良いはず。


358:login:Penguin
04/08/04 09:37 NoJQortH
>>357
3つのCPUおよびOSがある組込み系のデバドラを考えてます。
普通はioctlやselectをモジュール側に個別に書くのでしょうが、
それだとダメみたいです。デバドラ側で一括して処理を行うようにしないといけません。
ioctlをモジュール側から呼びだして、デバイス側ではそのioctl処理からpoll(割り込み処理)を
考えてます。なぜioctlかと言うと、ユーザデータをデバドラに渡したい(アドレスのチェック)からです。

359:login:Penguin
04/08/04 10:00 H7hK0Jjq
>>358
>ioctlをモジュール側から呼びだして、デバイス側ではそのioctl処理からpoll(割り込み処理)を考えてます。
ちょっと待てよ、そこで言ってるモジュール側とデバイス側の区別がわからないのだが?


360:login:Penguin
04/08/04 10:24 AG/Dol7k
一般に、デバドラ内部からシステムコールやライブラリ関数は呼べないよ。
書いてあることだけじゃいまいち要領を得ないが、taskletなりtask_queueなりを
自分で管理して、カーネルのスケジューラに登録するのが常套手段だ。

カーネルスケジューラはは2.2系 2.4系 2.6系で大きく異なるから
各バージョンすべてで動作する共通コードを書くのは結構大変
泣ける マジで

361:login:Penguin
04/08/04 14:21 NoJQortH
>>359
モジュール側とはライブラリのソースで、デバイス側とはデバイスドライバのソースです。
表現が下手ですね。文章もあまりうまくないのでごめんなさい。
ライブラリ側では、whileループでバッファの中身をチェックしています。
バッファが空になるまで、プロセスを眠らすことがそもそもの目的です。


362:login:Penguin
04/08/04 14:35 NoJQortH
>>360
ありがとうございます。げえ、かなり大変そうですね。。。かなり萎えてきました。
今いろいろいじくり回してて、デバドラのioctlのfile構造体のメンバf_opを、
poll(select)の関数を指すようにしてやっています。
そのために、ioctlとは別のfile_operation構造体をつくってそこでpollを宣言しました。


363:login:Penguin
04/08/04 14:40 +wO9AS9w
>>356 の言う「モジュール」=「ライブラリのソース」は「ユーザランドの
アプリケーションが使うライブラリ」かな?

364:login:Penguin
04/08/04 15:22 NoJQortH
はい。そうです。
わかりにくくてすいません。

365:login:Penguin
04/08/05 00:11 UYjeE7ll
>>362
なんか、あさっての方向に走ってないか?
- poll() したいなら poll() を実装する
- イベント待ちをしたいread()だろうがioctl()だろうがかまわず待て

やりたいことを確認したほうがいいぞ。
- なにをどう待ちたい?
- 付加的にやりたいことは何?

後者は、
> なぜioctlかと言うと、ユーザデータをデバドラに渡したい(アドレスのチェック)からです。
がわからんかったって話。


366:login:Penguin
04/08/05 00:11 UYjeE7ll
あうあ
- - イベント待ちをしたいread()だろうがioctl()だろうがかまわず待て
+ - イベント待ちをしたいなら、read()だろうがioctl()だろうがかまわず待て


367:login:Penguin
04/08/05 00:45 CMe3HEND
大丈夫か!? >>364よ!!
がんばれよ! 見守ってるからさ!

368:login:Penguin
04/08/05 12:51 dMydmJ+4
書いてあることだけじゃいまいち要領を得ないが

アクセス待ち、アクセス完了まで時間がかかる、排他処理が必要である
ようなデバイスで

・ノンブロックでアクセス処理したい
・複数のプロセスから同時にアクセスされる状況に対応したい
・複数のデバイスを一元的に管理したい (リソース管理など)

こんな条件だと勝手に仮定すると
たしかに大きいデバイスドライバを書いて、そこですべて管理するのも
ひとつの解決法ではある。
でもユーザランドでスレッド/子プロセスを使って、ノンブロック処理を
実装することも出来るし、唯一の解でもない。

まぁ、情報が出せないというよりは、状況を理解してないので
うまく説明できないって感じなので、もうちょっと頭を使って
問題を整理してから、もう一回質問するがよかろう

369:login:Penguin
04/10/29 11:01:48 rDkd0V/P
lsusbだとデバイス名が把握できてるということは、
個々のドライバ部分に問題があって動かないという風に考えてもいいでしょうか?
linux-2.6において
usbcore
uhci_hcd
cdc_acm
という三つのドライバにより動かしたいハードウェアがあるんですが、
cdc_acmをロードしてもうんともすんとも言いません

370:login:Penguin
04/10/31 20:53:26 fFX2rhTr
.netとかjavaみたいなバイトコードなドライバーでハードウェア
を制御する環境を作るって可能ですか?

371:login:Penguin
04/10/31 21:36:34 uzVMAm7i
>>369
まあそうでしょうな。
lsusbはハード的につながっていれば見えるし。

>>370
そりゃ作れん事は無いが…
速度が厳しくないかい?


372:login:Penguin
04/11/01 02:36:54 dfNRJQ4+
>>371
JITなりリコンパイラーなり方法はあるだろうし、全てのドライバーが
速度を必要とするわけじゃないと考えたわけで。部分的にでも・・・と
何にしてもバイナリの非互換性がどうにかならんかなぁと。

カーネル毎にコンパイルはダリ

373:login:Penguin
04/11/01 06:48:36 IqBdvM7D
>>370
Kernelから呼び出すような仕組みにしても、
Javaで言うnativeなのが無いと駄目じゃない?
レジスタとかメモリ領域さわれないし。
結局そこ(nativeなモジュール)で非互換性が出る気がする。

374:login:Penguin
04/11/01 15:55:17 lkrLxjNC
>>373
そのへんはバイトコードインタプリタで抽象化すればいいのではないかと。
PCIあたりならかなりの所まで出来そうな気がするなあ。

そういやOpenFirmwareなんてのがあったのう…あれはForthだっけ?


375:login:Penguin
04/11/01 22:34:23 dfNRJQ4+
成るほど・・・
>>373
やっぱりそういうところで不備が出てきますか。。。言語拡張で・・・となると
Javaじゃなくなるし、コンパイラーも自前に用意しなきゃならなくなるし。。。

>>374
漏れもそんな感じの考えでいたんだけど、やっぱそれが難しいんでしょうね。
とはいえ、可能性があることはわかりました。ありがとうございます。
>>OpenFirmware
調べてみましたが上の考えのBIOS版みたいなもんでしょうか?

とりあえず、神が現れることを祈りつつ作れる作れない、作る作らないは別として
自分でも調べてみようと思います。厨の妄想に付き合っていただきありがとうございました。

376:login:Penguin
04/11/02 12:28:29 lgEgFui9
カーネルのバージョンによってカーネルが持つ構造体が微妙に違うことがよくある。
(メンパが増えてるとか)

現状のinsmodによるデバイスドライバのダイナミックリンクは
その手の構造体の違いを解決してくれないので、原則的に
カーネルバージョンに依存したドライバしかリンクできない。

強制的に違うバージョンのドライバをinsmodすることも可能だが
正常に動く保証はない。たまたま動くことはあるけれども。

377:login:Penguin
04/11/02 18:53:41 chaRCRYs
まあソース見て「あーこれなら動くな」と思ったら
迷わず-f

378:login:Penguin
04/11/03 13:41:27 1PHyje+L
ドライバのソースがあるならリビルドする方がいいような気がするのう。
いっぱいコンパイラに怒られたりすると直す気が失せるが…


379:login:Penguin
04/11/06 23:30:41 9J0OxvoL
>>376
なるほど。JAVA云々無しにしてもやっぱカーネルとは別離すべきなのかも。
いや、マイクロ・モノリシックの話じゃなくて仕様的なものを。moduleの管理も
こんなんでいいの?って気もするし。Xもドライバー持ってるってのがよくわから
んし(嫌味とかじゃなくて本当にわからんのです。)

って偉そうな事言っててもしょうがないな・・・たまにはソースぐらい読もう・・・

380:login:Penguin
04/11/07 08:11:19 /P0s9FI4
>>636 > 昨日Linuxにふれたものですから
であり、(非常に一般的なやりかたにもかかわらず)やりかたがわからないとい
う人が tamagoをいれたい理由はなにかしら?
特に強い理由がないなら、「いれるな」が正しいガイドだと思うのですよ。

>>635
つかいかたは man xmodmap でみるといい。
キーコードは xev で調べられます。使いかたは man xev でみるといい。


381:login:Penguin
04/11/08 12:46:18 ir5Tmuq8
Xサーバはroot権限のユーザランドプロセスで /dev/ioとか /dev/memに
直接アクセスしてビデオチップを制御する。
Xのドライバといわゆるデバイスドライバとは動作メカニズムがまったく違う。

382:login:Penguin
04/11/09 23:51:44 +nDFjkMc
ユーザ空間からmmapでマッピングしてデバイスいじくるときって、
アプリがマッピング先のメモリに書き込む動作と同時に
デバイスにデータって書きこまれるんでしょうか?
バッファリングみたいのって気にしなくてもいいの?

383:login:Penguin
04/11/10 01:00:51 8UeNJl+2
>>382
デバイスをmmapしてアクセスするときは、単にMMUがそこを指しているだけで、
ディスク上のファイルをmmapしたときのようなバッファリングはありませんよ。
類似のがある場合はあって、それはキャッシュなのです。
/dev/fb* は通常キャッシュが抑止されています。
/dev/mem は O_SYNCでopenしてやるとキャッシュを抑止します。



384:login:Penguin
04/11/10 07:34:29 WP1ExQ+t
PCIデバイスの場合 各共有メモリ空間ごとにprefetchableビットが定義されている
ほとんどのPCIカードはprefetchableがdisableになっておりキャッシュ無効になってる

385:login:Penguin
04/11/10 14:40:19 OHaab6bm
>>383
>>384
CPUキャッシュですか。
環境にもよるのでしょうけど、基本的にはあまり気にしなくてもいいのですね。
実は、drivers/char/mem.c みたんですけど、mmap システムコールを呼んだときと、
そこにアクセスした時のコードの流れがよくわからないのでちょっと???でした。

あとは、コンパイラのオプティマイズも気にしておいたほうがいいのでしょうね。

386:login:Penguin
04/11/10 18:01:50 MrVsce1+
>>385
CPUキャッシュはユーザー空間から叩く手段がないので、
カーネルとハードウエア側の制御にお任せするしかないです。

最適化の方はvolatile付けておけば大丈夫でしょう。
なにもしないと最近のコンパイラは賢すぎてとんでもないことをやってくれますからな。


387:login:Penguin
04/11/10 23:54:53 8UeNJl+2
>>385
キャッシュは気にしてください。キャッシュがあると
. 書き込みがキャッシュが溢れるまでなされない。
. 読みだしも同様。
. 同一ラインにのる近隣のレジスタがいっしょにアクセスされちゃう
という、デバイスの制御にとっては致命的なことがいろいろ。


388:382 385
04/11/11 00:27:04 95L6p31P
すみません。
キャッシュを気にししなくてもよいと書いたのは、
キャッシュが働かないので、気にしなくても良いという意味で
書いていました。

387さんのおっしゃるとおり、デバイスアクセスでキャッシュが
働いてしまうと、ひどい目にあいますね。

ところで、mmapのキャッシュ無効化ってmem.cの
noncached_address を修正すれば有効無効をユーザで
任意に操作可能になるんですかね?
ハードやBIOSでキャッシュ関係の細工が何かあったりしたらだめなのかもしれませんが。




389:login:Penguin
04/11/12 00:12:24 nxDtrzpb
>>388
抑止の方は O_SYNC でできますよ。その行の後半の条件がそうでしょ?


390:login:Penguin
04/11/14 11:26:16 ZhMJfRu+
USBサブシステムを読んでいるんですが、
デバイス、バス、ドライバの三つの関係のイメージを
教えてください。なんだかソース読んでいてもよく分かりません。

またxxx_probeという関数に渡ってくるstruct usb_interfaceとは
どこで確保されいてる構造体なんでしょうか?

391:login:Penguin
04/11/21 11:06:40 RzBM8DsM
technokitのUSB-IOをFedora Core 3に接続したら、/dev/hiddev0が勝手にできたので、
これに対しCでプログラムを作って、
fd = open("/dev/hiddev0", O_WRONLY);
して、
write(fd, command, 8);
した。commandは0x01FF00000000。けど全然反応が無い。

USB-IOのエンドポイント0には、0x01FFを送ったら、ポート0が反転するはずなんだけどなあ。
hid使わずに、ちゃんと専用ドライバ使わないとだめなの?

392:login:Penguin
04/11/21 17:22:45 fkgrUhvM
デバイスドライバはカーネルメモリを消費するらしいのですが、
現在のカーネルメモリーの残量を知るにはどうしたらよいですか?

393:391
04/11/21 17:37:11 RzBM8DsM
>390 /usr/include/usb.h

394:login:Penguin
04/12/12 18:20:03 fch5Qtg6
Linuxデバイスドライバの勉強を始めました。
がまずは、オライリーの本で解説してる、
サンプルコードから入ろうと思ったんですが、
asm/system.hをincludeしているコードは、

/usr/src/linux/include/asm/system.h: 関数 `__set_64bit_var' 内:
/usr/src/linux/include/asm/system.h:190: 警告:
dereferencing type-punned pointer will break strict-aliasing rules

と警告を出されてしまいます。
同じ現象に遭遇した香具師いませんか?
コンパイラはgcc3.3、kernel2.4.26。
ちなみに、警告された部分は、
#define ll_low(x) *(((unsigned int*)&(x))+0)
#define ll_high(x) *(((unsigned int*)&(x))+1)

static inline void __set_64bit_var (unsigned long long *ptr,
unsigned long long value)
{
__set_64bit(ptr,ll_low(value), ll_high(value)); //190行目
}


395:394
04/12/12 18:22:17 fch5Qtg6
あ、マシンは i686です。

396:login:Penguin
04/12/14 01:02:15 bnBNd/cw
たしか-fno-strict-aliasingだったかな。それつけれ。
より詳細が知りたいときはググれ。

397:394
04/12/14 02:47:39 iNH7gUWs
産休です>>396

小細工ですが、
(unsigned int*)&(x)を、(unsigned int*)(void*)&(x)に書き換えると、
警告を封じることができますた。
勉強がんばります。

398:login:Penguin
04/12/14 11:29:27 HO3MDnt+
モジュールでmallocを使うと
implicit declaration of function `malloc'
なる警告が出ました。
正直、うまくいくとも思っていなかったのですが、ためしにやってみた感じです。
何かヘッダをincludeすればいいのでしょうか。

399:login:Penguin
04/12/14 11:44:22 vlh4D4yl
>>398
kmalloc() or vmalloc()

400:login:Penguin
04/12/14 11:54:53 HO3MDnt+
>>399
感謝.あとは調べます.

401:login:Penguin
04/12/14 15:55:34 ScDxM3L+
【序 論】
オウム事件とは、「オウム、創価、統一が共同でやっていた覚醒剤密造などの不法行為がばれそうになり、全ての罪をオウムに押付けた。」事件であると理解しています。
統一教会は、その起源から考えて、KCIA及びCIAの影響下にあると考えるべきです。
日本側のCIA専属のお爺さんたち、つまり、笹川さん、児玉さん、中曽根さんたちが、統一とつるんでいたのも、CIAの犬同士という絆があったわけです。
一方で、創価は創価で、笹川一派を通じて、統一と繋がりがありますし、それ以前に創価内部に深く入り込んでいる暴力団、
後藤組のもつ北朝鮮コネクションから、オウムの麻薬ビジネスに関わっていたわけです。
もちろん、日本社会に創価マフィアのネットワークをはりめぐらした学会を、CIAが放っておくわけがなく、マネーロンダリングなどに、しっかり利用されています。
宗教法人の財務の閉鎖性をCIAが利用しないと考える方が異常です。
そして、CIAお得意の麻薬ビジネスの日本支部が、オウムだったわけで、その収益が北朝鮮に還元されていたのも当然のことであり、
北の現体制を維持するための、CIAの有難い配慮だったわけです。
なにしろ北の体制が崩壊すると、一番困るのは、CIAのスポンサーである軍産複合体と国際金融資本であり、極東の緊張は、彼らの飯の種なわけですから。
麻薬王にして、CIAの帝王である大ブッシュさんが、統一の文と仲良しなのも、アッタリマエなわけですね。
今度の米大統領選でも、随分と統一のカネが小ブッシュ陣営に流れたようですね。
尚、本件の主たる議論は、2チャンネル、警察板の「告発します 第3部」スレッドにて、進めています。
URLリンク(mentai.2ch.net)

402:login:Penguin
04/12/14 17:02:39 WBCZfumK
国際金融資本と無関係な人はいません。ここが大事なところです。
国際金融資本とダーティーな勢力になんらかの関係があるというのなら、
全ての人間がダーティーな勢力と関係があるということです。

403:login:Penguin
04/12/16 00:42:54 HSUTNn3s
<linux/errno.h>をincludeしているのに、errnoが宣言されていないとエラーが出ます。
なぜですか?

404:login:Penguin
04/12/16 00:52:12 fnG8qWZe
#include <asm/errno.h>


405:login:Penguin
04/12/16 03:08:53 L4JhEJTY
デバイスドライバーをイジルとハードが壊れます

406:login:Penguin
05/01/13 20:25:56 5Qhjx5GH
jiffies の質問です。jiffies がオーバーフローする時の挙動を確かめ
たく、下記のようなモジュールを作成してロードしたのですが、モジュー
ルのロードに非常に時間がかかります。

#define __KERNEL__
#define MODULE
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/delay.h>

MODULE_LICENSE("GPL");

int init_module(void)
{
jiffies = 4294961296UL;
return 0;
}

void cleanup_module(void)
{
return;
}

即座に jiffies 値を変更するためには、何か工夫が必要なのでしょう
か?


407:login:Penguin
05/01/13 21:59:07 b26g+4JK
>>406
jiffesの値が飛ぶせいじゃないの?
初期値をいじる方がいいと思うが。


408:login:Penguin
05/01/13 22:21:10 5Qhjx5GH
やっぱりそれしか方法ないでしょうかね。カーネルコンパイルが億劫で
まだ試していませんでした。

例えば、jiffies += 8640000; だとそれほど時間はかからないのですが、
jiffies += 8640000; にすると、より多くの時間がかかるようです。仮
想マシン環境で実験しているのですが、その間、仮想マシンのプロセス
の CPU 使用率は高いままでした。


409:login:Penguin
05/01/14 02:03:54 PSu0RjKD
ん? 何書いてたんだ、俺
>408 は、正しくは以下です。

例えば、jiffies += 8640000; だとそれほど時間はかからないのですが、
jiffies += 864000000; にすると、より多くの時間がかかるようです。


410:login:Penguin
05/02/06 11:19:02 +OMlHKxZ
mmapによるデバイスアクセスについてご教授ください。

16bitアクセス限定のデバイスに対して、
mmapによるアクセスを試行しているのですが、
どうも挙動が怪しくて困っています。

アプリ側からmmap(/dev/memをO_SYNCでopen)してshortアクセスをしても、
そのままshort幅でデバイスにアクセスが行くとは限らないのでしょうか?
なにか考慮が不足してるのでしょうか。

411:login:Penguin
05/02/06 14:33:57 JfjjYGk4
>>410
アーキテクチャわかんないので、過去の経験より。
・D cache
・コンパイラが勝手に最適化

そういう制限がある場合は、おとなしく専用ドライバ書くのが
近道のような気がしますな。


412:login:Penguin
05/02/10 21:10:10 oT40ukFS
gcc 3.3.5(gentoo) で作成したモジュールを gcc 3.4.2(FC3) のPCへ
組み込もうとするとエラーで組み込めません。
どちらも kernel-2.6.10 です。

insmod: error inserting 'hoge.ko' : -1 Invalid module format

kernel config (General setup, Loadable module) は同じにしてあります。
同じバージョンの gcc で作成したシステムでないと無理なのでしょうか。

413:login:Penguin
05/02/12 01:22:07 QcR6E3eX
>>410

>>411の言うとおりアーキテクチャが分からないのでなんともいえないけど・・・

/dev/memをmmapでshortアクセスしたら、普通はshortで触ってくれるでしょう。
でも、触ってるデバイスが * 例えば32bit PCI * にぶら下がってたりしたら
32bit で触りに行っちゃうこともありますよ。
っていうか、PCIの向こうにいるデバイスに届くまでに余計な16bitが増えてたりする。
それでも、読みにいくときには多分shortで行っても多分大丈夫。
書き込みをshortでやったりすると、残りの16bitにゴミが乗っかっちゃうとか、
そんなんじゃないでしょうか?

そうならば、shortで書きに行くときには、最初にデバイスから32bit分持ってきて、
それに16bit分上書きして、32bit書き戻すとかするしかないのでは。
(16bitアクセス限定でも、読みに行くときは16bit×2で32bit分をうまく返してくれることを
かってに期待して書いてますけど)

それから、32bitでアクセスするときにも触りに行くアドレスに注意が必要ですよ、多分。
32bitアラインメントじゃないとダメな予感がします。
もしそうならば、アラインメントの境界をまたいじゃうような16bitの書き込みをする場合、
両側の32×2 = 64bit分を持ってきて16bit書いて戻す、とかしないとダメですよね。

もちろんこれは、PCI上でうまく振舞うように作られていないデバイスの話で、
たとえ16bitアクセス限定デバイスでもそうならないようにつくることは可能だと思います。

ところどころ言ってるかもしれませんけどね・・・

414:413
05/02/12 01:24:29 QcR6E3eX
早速、間違えてました(w

>ところどころ言ってるかもしれませんけどね・・・

ところどころ * うそ * 言ってるかもしれませんけどね・・・


415:410
05/02/16 00:46:02 E/KjMwKc
いろいろ情報ありがとうございます。

もともとドライバ経由でアクセスしていたのですが、
パフォーマンス的な問題でmmapでを使用したかったという経緯があります。
ですが、mmapだとどうもうまくいかなくて試行錯誤していた次第です。

ですので、単純にmmapでの処理の問題かと思っていました。
時間はあるので、勉強も兼ねてもうちょっと情報収集をしたいと思います。


416:login:Penguin
05/02/16 22:28:50 mypLuczy
URLリンク(www.netfort.gr.jp)
これカコイイ


417:login:Penguin
05/02/20 21:06:04 0sjUjbHi
現在、デバイスドライバ作成(とりあえずキャラクタ型)の勉強しているのですが、
2.4.30-pre1上で作成したテストドライバでモジュールのロードは成功したと思われる
のですが(lsmodで存在を確認)、実際にドライバを使用する為に作成したテストツールから
呼び出す(ioctlを使用する箇所で)と失敗しました。

$ ls -l /dev/testdev
crw-rw-rw- 1 root root 60, 0 2月 20日 20:11 /dev/testdev
$ ./testtool
ioctl: Inappropriate ioctl for device <-- perrorで表示させてみたところ


418:417
05/02/20 21:09:12 0sjUjbHi
つづき

そこで、さらに詳細に状況を確認するためにstraceを使用してみました。
$ strace ./testtool
execve("./testtool", ["./testtool"], [/* 52 vars */]) = 0
brk(0) = 0x8049a6c
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=62075, ...}) = 0
old_mmap(NULL, 62075, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40013000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0DU\1\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1333605, ...}) = 0
old_mmap(NULL, 1145796, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40023000
mprotect(0x40134000, 27588, PROT_NONE) = 0
old_mmap(0x40134000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x110000) = 0x40134000
old_mmap(0x40139000, 7108, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40139000
close(3) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4013b000
munmap(0x40013000, 62075) = 0
open("/dev/testdev", O_RDWR) = 3
ioctl(3, FIBMAP, 0xbffff1d8) = -1 ENOTTY (Inappropriate ioctl for device)
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40013000
write(1, "errno = 25\n", 11errno = 25
) = 11


419:417
05/02/20 21:10:12 0sjUjbHi
つづき

dup(2) = 4
fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR)
brk(0) = 0x8049a6c
brk(0x804aa6c) = 0x804aa6c
brk(0) = 0x804aa6c
brk(0x804b000) = 0x804b000
fstat64(4, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000
_llseek(4, 0, 0xbfffef50, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(4, "ioctl: Inappropriate io"..., 47ioctl: Inappropriate ioctl for device
) = 38
close(4) = 0
munmap(0x40014000, 4096) = 0
close(3) = 0
munmap(0x40013000, 4096) = 0
exit_group(1) = ?
$

結果を見ていると実行したおぼえのない以下の行がありました。

ioctl(3, FIBMAP, 0xbffff1d8) = -1 ENOTTY (Inappropriate ioctl for device)

この現象はどこにエラーがある場合におこり得ますか?
知ってる方お願いします。m(_ _)m

420:login:Penguin
05/02/20 21:38:19 uvzGFsyf
結果じゃなくてソースだそうよ

421:417
05/02/20 21:48:59 0sjUjbHi
>>420
Please wait for a moment...

422:417
05/02/20 22:06:08 0sjUjbHi
#define MODULE
#define __KERNEL__
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/sched.h>
#include <linux/fs.h>
#include <linux/string.h>
static int devmajor=60;
static char *devname="testdev";
MODULE_PARM(devmajor, "i");
MODULE_PARM(devname, "s");
#include <asm/uaccess.h>

static int devtest_open(struct inode * inode, struct file * file){
MOD_INC_USE_COUNT;
return 0;
}

static int devtest_close(struct inode * inode, struct file * file){
MOD_DEC_USE_COUNT;
return 0;
}

static int devtest_ioctl(struct inode *inode, struct file *file,unsigned int cmd, unsigned long arg){
int i;
printk("testdev: ioctl: cmd=%04X\n",cmd);
switch(cmd)
{
case 1: printk("Driver testing\n"); return 0;
}
return -EINVAL;
}


次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

5366日前に更新/265 KB
担当:undef