ディバイスドライバをハックしよう！

ディバイスドライバの改造、製作にまつわる情報交換、質問、
噂話、ぐち、政治、経済に関するスレです。できる限り生産的にいきましょーや。

>>802>>803
それだとinsmod以外にも必要になるんじゃないんですか？
関数で無いですかね
(init_moduleから呼び出す)

insmod hoge
だけ実行すればアプリから叩けるような形にしたいんですが…

shell スクリプト作ってその中で insmod、mknod すれば？
rmmod も出来るようにすれば、なお良いでしょ？

>>805
それが良さげですね。
ありがとうございました。

>>801
mknodしたくないってだけなら、device_create(9)か、手を抜きたいなら
misc_register(9)に全部にまかせれば、>>802が言ってるように、udevが勝手に
スペシャルファイルを作ってくれるんじゃないか？

ブロックデバイスのブロックサイズってどこで決まってるの？
ユーザアプリから見る方法ある？

>>808
mkfsする時に決まると思うが。
ext2/ext3 なら tune2fs -l で見るか、ファイルがあれば stat構造体の st_blksize を見る。

>>808
そのブロックデバイスドライバが制御しているハードの規格によりだね。
SCSI系ならMode Senseコマンドで取れたんじゃないっけ？

>>808
試してないけど、blktool(8)のblock-szコマンドでいけそうかもね？

>>809
フォーマットする前に最適値を知っときたい乙女心です

>>810-811
ありがとう。でもハードの規格というよりブロックデバイスとして
なんかその辺を返してくれるioctlなりなんなりがあったらいいな
とか夢想してた

>>807見て、misc_register調べてちょっと使ってみたんだけど、
これで作ったもんどうやって消すんだ？

関数自体は使い方分かったが、対になるもの無い？
misc_register込みのinsmod→rmmod→再度insmodでハングするんだが

書いた直後に自己解決しちまったorz

misc_deregisterがあるのね…
スレ汚しすまんかった

ほ？

mmapを利用して物理アドレス0x10000000に存在するデバイス(SRAM)のR/Wを
行うドライバを作成しようと思っています。
馬本の第３版のサンプルソース(simple)を参考にしながらremap_pfn_rangeで
マッピングし、ダンプをとってみたところ、0x10000000エリアのデータでは
なく、全て0のデータが読み取れました。
0x1000等の小さい物理アドレスであれば正常にリード出来ているようです。
0x10000000のように上の方のアドレスは、remap_pfn_rangeではマッピング
されないのでしょうか？

カーネルのバージョンは2.6.11です。

/dev/mem openして
memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x10000000)
memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x1000)
でも同じ結果でした・・・

訂正
>>817
>memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x10000000)
>memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x1000)
mmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x10000000)
mmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x1000)

訂正
>>817
>memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x10000000)
>memmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x1000)
mmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x10000000)
mmap((void*)0, 0x1000,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0x1000)

Linux 2.6.11 使ってないしためしてないけど、
/sys/devices/pci*/*/resource? を mmap(2) って出来ないんだっけ？

とりあえず、落ち着けｗ
man mmap2

>>821
>man mmap2
↓ですよね？
http://www.pinkdragon.net/doc_lib/contents/ja/linux_man/mmap2.2.html
Linux 2.3.31 以降で使用可能とありますが、この環境では定義されていないと言われます。
組込み系だからなんでしょうか・・・

それと馬本第３版のP437　15.2.6 RAMのマッピングを変更する　に
「ramap_pfn_rangeがRAMを扱えないことは・・・」ってくだりがあります。
実際いま起きている問題はこれなんでしょうか？
ioremap_nocacheでReadする方法とダンプ比較したところ,mmapだと
0x00000000〜0x00800000 あたりまではちゃんとよめますが、
0x01000000になったとたん、0x00000000の値になってしまいます・・・
ioremap_nocacheでは0x01000000も見れるのに・・・

MTD使えばいいんじゃない?
phram.koとか
slram.koとか

タスクレットの中でsleep_on_timeoutって呼べないんですか？
なぜかカーネルパニックになってしまいます…

タスクレットからkill_fasync()呼びたいんですけど、
第一引数ってどこから持ってくればいいんでしょうか？

フリーオのデバイスドライバー書ける人が居たら神！

玄箱用のは、あるだろ

あげあげ

ttp://pc11.2ch.net/test/read.cgi/linux/1213378360/

やっぱり情報公開されてない物のドライバ造るのって無理がある？
Willcomスマートフォン端末でLinuxを動かすプロジェクト？があるのですが、
WS003SH、WSはPrismチップの無線LANを使用。
WS011SHではSharp独自のチップを使用した物のようです。
WS020SHは不明。

当方WS011SHの物の開発に興味があるのですが、難しいどころか情報の公開がされていない限りは
手すら付けられない状態でしょうか？
アドバイスよろしくお願いします。

copy_{to,from}_user()でユーザプロセスのアドレスを与えるところにカーネル空間のアドレスを与えるとどうなります？
やっぱりaccess_ok()で弾かれる？

>>831
その程度、自分で確認しろ。

あげ

Linuxデバドラ移植の質問です。
雑誌の記事でx86Linuxデバドラを他CPUのLinuxに移植する際に、デバドラのソースが
x86に依存してて移植できないことを知りました。
どうやらx86プログラマが他のCPUへの移植性を考えずに開発したことが原因みたいです。

雑誌によるとデバドラの依存箇所は以下が多いようです。
・バイトオーダ
・アライメント
・I/Oアクセス
・タイミング

皆様に質問ですが、このようなx86に依存したLinuxデバドラが落ちている場所を
ご存じないでしょうか？
また、根本的なことですがx86Linuxデバドラを移植したり、移植しようとしたが
x86に依存してて大変だったという案件は多いのでしょうか？

どうぞよろしくお願いいたします。

>>834
drivers/

直すのはそんなにめんどくないが、どこに地雷があるかわかりにくいのがのう。

>>834
というか、デバイスドライバは基本的にハードに依存して当然
という側面も否定できないと言わざるを得ないこともあるので。

カーネルソース内にあるんですね！
知りませんでした；

私は初心者でよく知らないんですが、てっきりカーネルソール内のコードって
移植性をちゃんと考えてあって（arch/以外）、管理されていると思ってました。

むしろ、カーネルソース外の開発（企業or個人）で公開されているドライバに
あるのかと思ってました。

>>834
ふつー開発者の持ってるCPUでしかテストしないよ。

tg3とかe1000とかはNEC(ia64)とかIBM(powerpc)とかが
頑張って自分とこのハードで動くようにしてるけど、
個人でハックしてるものはたいていx86だけ。

まあ、過去の経験からすると
・USBターゲット - ほとんど手を入れる必要無し
・PCI - そんなに苦労することはない
・CPU直結 - 健闘を祈る
てところですかねえ。

age

USBデバイスでも無線LANとかは

age

HWからの割込み処理中の、ローカルAPICへのEOI発行タイミングについて質問があります。
レベル・トリガの割込みだった場合は、end関数からEOIを発行しています。
これは、割込み処理の先頭で発行してしまうと、I/O APICへEOIが通知され、デバイスのアサートが
失われてしまうのが不都合だからでしょうか？
カーネルのverは2.6.18 です。

>>843
一般的な話だけど
割り込みに関わるのは３つ。
�@割り込み発生の条件と、割り込み要求するデバイス
�A割り込みを調停する割り込みコントローラと、割り込み受付のカーネル
�B実際の割り込み処理プログラム

�@→�A→�Bの流れは分かるよね
それなら質問の答えも分かるよねｗ


わんこ蕎麦に例えると
�@>>843のお椀の蓋が開いてる
�A>>843のお椀に蕎麦を放り込むおばちゃん
�B蕎麦を食べる>>843

満腹になった>>843�Bが最初にすべきは、�@の処理か�Aの処理か

>>844
「ご馳走様でした」と言いながら金を払わないで蓋も開けっ放しで逃げる。

ダブルフォルト乙

(1)はおばさんのスピードに勝てないと判断して、(2)のおばさんに話し掛けるよな
もうお腹いっぱいって

a

ポートIOするサンプルを作ってみようと思ったのですが、
下のコードの時点で、すでにコンパイルが通りません。
sys_ioplを呼ぶのに、何が足りないのか分からないです。
どうしたら良いか、アドバイス頂けたら助かります。
よろしくお願いします。

debian 2.6.24 gcc 4.1.2

make -C /lib/modules/2.6.24/build M=/test module
error: implicit declartion of function 'sys_iopl'
---
#include <linux/init.h>
#include <linux/module.h>
#include <linux/io.h>
#include <linux/ioport.h>

static int __init
hello_init(void){
sys_iopl(3);
return;
}

static void __exit
hello_exit(void){
return;
}

module_init(hello_init);
module_exit(hello_exit);

すみません、sageてしまいました。

根本的に間違っているような気がするので、
もう少し具体的にやりたいことを書いた方がいいと思う。

取り合えずドライバでioplはいらねえ。

>>851
もしかして、ﾄﾞﾗｲﾊﾞ内では、ポートにアクセスするのに、iopl自体が使えないということでしょうか？
そうすると、request_regionしていくしかないということですかね。
それとも、アクセス許可自体が必要ないのでしょうか。


元々、独自PCI-I/Fボードにアクセスするアプリがありまして、
それの、ドライバ版を作ろうと思いました。
そのアプリでは、iopl(3)→outb(),inb()にて値を取得していたので、同じ様に作っていたところでした。
PCIからのポートアドレス取得が上手くでき、そのアドレスにアクセスする段階だったのですが、
ioplでどうしてもコンパイルが通らず、includeの問題なのか、Makefileなのか、
途方に暮れてました。>>849はそのテストプログラムを抜き出しです。

なんでドライバにする必要があるのかよくわからんが。
そういうレベルでわからんのであれば、まずは馬本で基礎知識を
身につけた方がいいと思う。

ついでに、sys_ioplの呼び方はそうじゃない。
つうかカーネルの中でsys_〜は直接呼ぶもんじゃない。

>>853
ありがとうございます。
ドライバ版の意図は、いずれ割り込みを使うつもりだったからです。
馬本は十分理解できなかったので、とりあえず作ってみるという感じでやってました。
sys_ioplは呼んではいけないんですね。
馬本、もう一度読んでみます。

馬本はカーネルの知識がある程度ある前提で書かれてるので
まずはLinuxカーネルに関する文献を読んでみることをおすすめするよ

デバイスドライバはカーネルの一部でもあることを忘れるな

Kernel 内で IN/OUT アセンブラ命令に相当するのは
何かマクロがあるんじゃなかったっけ？

READ_PORT とかそんなの。

in[bwl]
out[bwl]
とか。
include/asm/io.hに入ってたはず。

シリアルドライバ内の情報で、何バイト受信済みとか、何バイト未送信という情報って
取得することは可能ですか？

補足です。
上記の情報をアプリケーションから取得できますか？

>>859
ioctlでTIOCINQとかTIOCOUTQみれば出来そう。
つーかマニュアル嫁よ。せっかくあるんだからよ。

ヌルイぞ。そこは

　つーかソース嫁よ。せっかるあるんだからよ。

だろ。ソース以上の資料なんかないんだからOSSってのは質問禁止なんだよ。

・・・ってえらいひとがいってました！

>>861
その偉い人は馬鹿だよ

どこでも、えらい人は馬鹿なもんさ。

保守上げ

>>861

×　だろ。ソース以上の資料なんかないんだからOSSってのは質問禁止なんだよ。

○　だろ。ソース以外の資料なんかないんだからOSSってのは質問禁止なんだよ。

i386BSDカーネルの386BSDカーネルソースコードの秘密
ソース以上の資料なんかないんだから、に対して何か書いてあったな。

>>866
ソースそのものと、ソースにこめられた趣旨は別じゃないかな？

UTSL だな。

linuxmintとウィンドウズ７ＲＣを使っています。ＷＩＮ7は試用なので来月から起動後一時間で自動で電源が落ちるようです。
リナックスに乗り換えるのは簡単なのですが、今使ってるテレビチューナーのドライバがリナックスには無いのです。
だれかmvp-rx3のドライバを書いてください。
このままではリナックスでテレビが見られず、リナックスをあきらめてウィンドウズのところにお嫁にイかされてしまいます。
テレビを見るためにはリナックスをお慕いもうしあげていますのにウィンドウズを買わなければならない境遇に
どうかどうか同情をしていただけるスーパーハッカーの方はドライバ書いてくださいませんか。
生きていくためには愛をもあきらめゲイツに身をゆだねなければならないのかと震えております。
ちなみにあたし女子中学生です。生娘です。似ている芸能人は１７歳のころの広末涼子です。

>>869
GV-MVP/RX3
http://www.iodata.jp/product/tv/analog/gv-mvprx3/

mvp-rx3はアナログTVキャプチャーボードですね。
2011年7月にアナログテレビ放送が終了するので
どのみち地上デジタルテレビチューナーが必要になります。
Windows7を買う金でPT2を買ってLinuxで使う方がよいと思います。
PT2なら地デジでもコピーワンスによる不便から逃れられます。

日経Linux 2010年2月号
http://itpro.nikkeibp.co.jp/article/MAG/20100105/342880/
> 特集2
> PT2で地デジ録画システムを作る
> パソコンで地上デジタル放送や衛星放送を受信できる
> デジタル・チューナ「PT2」を使ってシステムを作ります。
> 最新のLinuxディストリビューションのFedora 12とUbuntu 9.10で
> PT2のドライバをインストールし，高画質のテレビ番組を見てみましょう。
> 番組表から録画予約する方法も紹介します。

【視聴】Linuxでデジタル放送【録画】
http://pc11.2ch.net/test/read.cgi/linux/1230616112/

デバイスクラスがCDCでバルクでデータ転送するUSBドライバを作りたいんですけど、usb-skeltonドライバのベンダーIDとプロダクトIDを変更すれば使えるのでしょうか？

ioctlについて教えてください。

ioctlのパラメーターで指定するIDはlinux/ioctl.hで定義されているIOWやIORを使います。
しかし、アプリ開発者に渡すヘッダにIOWなどを使ってしまうと、ioctl.hはカーネルヘッダなので
アプリ開発者に渡せません。

ioctl.hごと渡すという手もありますが、ioctl.hの実態はarchの下を辿っていったものなので、
ずばりIOWなどが定義されているioctl.hを渡してしまっては、アーキテクチャを隠蔽している意味が
薄れてしまいます。
かと言って、別にヘッダを作っては無駄です。

これは、本来はどのように解決することを想定されているのでしょうか？

ビルド環境に入っているものを素直に使う。

>>873
ビルド環境？
すみません、Linuxはドライバの開発とOSの移植しかやったことがないので、
ビルド環境がよくわかりません。
ドライバを開発するうえで、アプリ屋さんにどのようにドライバのヘッダファイルを
渡すのが正しいやり方なのかを知りたいです。

?ttp://homepage3.nifty.com/rio_i/lab/driver24/00205ioctl.html

分かりました。
ioctl.hはわざわざ渡さなくても、アプリ開発で使用するカーネルヘッダに入っているので
大丈夫ということですね。
ありがとうございました。

ドライバコンパイル時に静的ライブラリをリンクさせることって出来ますか？

はい

どうやったら出来ますか？
2.6系のカーネルですが、-lでライブラリを指定しても
WARNING: "hoge" [/home/hoge.ko] undefined!
と言われてリンクできないんですよ。

.koってライブラリじゃないよ

そもそもgccやbinutilsはWARNINGとか大文字は出さないだろう
何かすごい勘違いしてそう

>>879
そもそも -l のかわりにソース直指定ならリンクできるのか？

webcam(UVC)を接続すると、/dev/video0にデバイスが作成されますが、
ここから流れてくるフォーマットについて知りたいのですが、どこか
参照するところってありますでしょうか？

おめおめ！

Cライブラリのassert()のドライバ版みたいなのないですかね？
勉強用にドライバを書いているのだけど、エラーチェックにいちいち if文を書くのが面倒くさい。
普通のアプリの場合は、assert()で一行でエラーチェックを終わらせるのだけど。
無いなら、どうやってエラーチェックしてるか教えて貰えるとありがたい。

BUG_ON

タイプ数減らしたいだけなら自分でマクロ書けばいいじゃん

#define assert(x) なんとかかんとか

>886
どうもありがとう。良い情報を頂きました。

>887
最悪その方法を取るけれど、既存の洗練された方法があるならそっちを使うべきでしょう？

PCIの自作用穴あき基板ってあるんですかね？
自作基板をスロットに差してデバドラも自分で書いて使ってる人います？

FPGAでプログラムする人とかいるんじゃないかな

>>889
サンハヤトで売ってる
ttp://www.sunhayato.co.jp/products/details.php?u=242&id=07008
もう生産終了して在庫のみみたいだが…

・FPGAにPCIバスコントローラIPを組込む
　(QuickPCIのようなPCIコア搭載のASSPも可)
・PLXのPCIバスブリッジLSIを使う

とかが簡単かな?
ただし、多chロジアナかPCIバスアナライザがないとH/Wのデバッグつらそう

>891
なせばなるってか。
http://elm-chan.org/works/pci/report.html

USB highspeed で足りなくなる用途ってのがなかなかなくて
なんか作る前に PCI がオワコンになってしまた。

汎用のPCIプロトコルICがあればいいのにね
プロトコルが複雑なせいで使いにくいよ、PCIは

>>893(やーさん)
891が言ってるPLXのPCI bridge LSIが、いわゆる汎用のPCIプロトコルICだろ?
ttp://www.plxtech.com/products/fastlane/
ttp://www.plxtech.com/products/expresslane/bridges

>894
MOUSERで買えるんだな。知らなかった。
俺が知ってるのはこっち。
http://shop.trenz-electronic.de/catalog/product_info.php?products_id=801

PCIってバスマスタ機能ついてないと強烈に遅いからなぁ
ターゲットアクセスONLYだったらUSBの方が全然マシ

USBはターゲット側から割り込みかけられんのがなあ
3.0が一般的になれば解決しそうだが

http://page2.auctions.yahoo.co.jp/jp/auction/b124613538
旦那、アナライザが出てきましたぜ

>>898
一瞬安いと思ってしまったが、いまさら使い道ないよなぁ

create_workqueueでカーネルスレッドいっぱい作るドライバが多いな
core-i7とか12個もできたりする

NICレジスタのとあるフィールドを、MMIOを使って書き換えようとしています。

１．pci_get_device()でデバイス情報取得
２．pci_resource_start()で物理アドレス取得
３．ここで、一応request_mem_region()をコールしますが、既にベンダー提供の
デバイスドライバでrequest_mem_region()されているので、0が返ってきます。
が、構わず続けて、
４．ioremap_nocache()でマッピングされたアドレスを取得

４．の結果を以ってレジスタのREADはできた（ethtool -dとの比較結果が一致)のですが、
writeb()を使って書き込んでも反映されていません(ethtool -dで確認)。

そこで質問なのですが、既にrequest_mem_region()されているレジスタについては、
READはできてもWRITEは不可といったことなんでしょうか？
それとも、他にフラグ操作等足らない操作があるのでしょうか？

同じリソースに2ヶ所（個別の管理している？）からアクセス(書き込み)したら、どうなるかわかってる？

>>902
実際にはある条件を満たすパケットを捨てる／捨てないを担う1bitの書き換えなのですが、
それでも横から弄られたら破綻するかなと思います。

そもそも、ベンダー側ドライバがこのbitを操作するioctl()なりEXPORT関数なりを用意
してないので、サポート外動作というのは理解しています。
一応、この辺はベンダー側にNDAでもいいんで提供してもらえるように依頼しています。

今回は、それまでに時間がかかるのでとりあえずでも弄ることができないかとあれこれ
やっています。
最悪は、このbitをドライバロード時に設定しているドライバソースを弄ればなんとか
なりそうなんですが、ソースを弄ることなく外から設定できるといいな、と。