☆Linux カーネルの仕組みを勉強するスレ☆
■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin
01/10/02 17:44ID:38KkZsUQカーネル全般について語り合うスレッドです。
0598login:Penguin
03/02/26 06:26ID:awPWSoM5$ man gcc
$ info gcc
0599login:Penguin
03/02/26 22:59ID:5ThntVhsマニュアルは質問する前に読みました．
問題は"/usr/include/linux" -> "../src/linux/include/linux"
というシンボリックリンクが張られているにも関わらず，
gccで-Iオプションを付ける必要があったということなんですが・・
0600login:Penguin
03/02/27 00:58ID:1e6KPqQp0601login:Penguin
03/02/27 04:16ID:a1jqWrjyはい．カーネル本やサイトでのコンパイルの書式にも-Iオプションは含まれていませんでした．
シンボリックリンクがあるから当然なことかもしれませんが．
カーネルコンパイルの時にモジュールもコンパイルしたのですが，その時には-Iオプションを
付けていたのでもしかしたらと思い，-Iオプションを付けるとコンパイルできたのです．
0602login:Penguin
03/02/27 13:43ID:t9JDv6rvリンク張った先がincludeの検索パスに入っていなかったとか。
0603login:Penguin
03/02/27 21:05ID:K7wez/ac/usr/includeがパスに入っていることは確かです．
他のユーザプログラムはちゃんとコンパイルできましたから．
/usr/includeがパスに入っていれば#include <linux/kernel.h>とすれば，
/usr/include/linux/kernel.hがインクルードされると思うのですが・・
で，"/usr/include/linux" -> "../src/linux/include/linux"なので，
/usr/src/linux/include/linux/kernel.hがインクルードのはず．謎です．
0604login:Penguin
03/02/27 22:07ID:U6VMdoGiasmは？
0605login:Penguin
03/02/27 23:34ID:ysi2QcED"/usr/src/linux/include/asm" -> "asm-i386"
です．ちなみに今回のモジュールは>>582のやつです．
asmはincludeしませんでした．
コンパイル後は正常に動作しています．
0606login:Penguin
03/02/28 00:14ID:oFO1qwF8おぷしょんは? -nostdinc がついてるとかいわない?
0607login:Penguin
03/02/28 03:36ID:Ph9QX781-Iオプションを付けない場合のエラーの行数が膨大すぎてよくわかりません．
出力のリダイレクトもできないようですし・・・
試しに-nostdincを付けてコンパイルするとincludeファイルが無いという
エラーが出るだけです．
0608login:Penguin
03/02/28 12:46ID:oFO1qwF8ちょっとまった。
もとのエラーはなに? includeファイルがないってエラーじゃなかったのかな?
それと、リダイレクトなら make >& ファイル でできるとおもう。
0609login:Penguin
03/02/28 13:55ID:ij45/eSjincludeファイルがないので、そこでの宣言に依存する部分が
山ほどエラーになるって事では？
>>607
リダイレクトするなら、-v付けて途中経過も見れた方がいいかも。
0610login:Penguin
03/02/28 16:12ID:HFAciNpD>もとのエラーはなに? includeファイルがないってエラーじゃなかったのかな?
はい．ヘッダファイル内での大量のparse errorやundeclaredです．
>>608,609
結局端末のスクロール行数をでかくして見てみました．エラーは
/usr/include/linux/kernel.h:73: parse error before `size_t'
/usr/include/linux/kernel.h:75: parse error before `size_t'
/usr/include/asm/string.h:47: parse error before `size_t'
/usr/include/asm/string.h: In function `strncpy':
/usr/include/asm/string.h:61: `src' undeclared (first use in this function)
/usr/include/asm/string.h:61: (Each undeclared identifier is reported only once
/usr/include/asm/string.h:61: for each function it appears in.)
/usr/include/asm/string.h:61: `dest' undeclared (first use in this function)
/usr/include/asm/string.h:61: `count' undeclared (first use in this function)
.....という感じです．
0611login:Penguin
03/02/28 18:52ID:Mjgg1ddGわかったよ、ママン
0612login:Penguin
03/03/01 00:24ID:jndZSd0z/usr/include/linux はもともとglibc-kernheaders に含まれるヘッダがおかれる場所だろ？
ユーザプログラムで使うヘッダだよ。
あと、-Iで指定するなら/lib/modules/`uname -r`/build/include の方がいいな。
0613login:Penguin
03/03/02 03:29ID:Lshpa1Id>/usr/include/linux はもともとglibc-kernheaders に含まれるヘッダがおかれる場所だろ？
>ユーザプログラムで使うヘッダだよ。
そうだったのですか．
カーネル空間のプログラムを作るときは使うべきではないのですね．
>あと、-Iで指定するなら/lib/modules/`uname -r`/build/include の方がいいな。
そうします．リンク先をミスするのを防ぐためですね．
ありがとうございました．
0614login:Penguin
03/03/02 05:04ID:FJ0TV1/oマジスか。知らんかった・・・
というかどこかで
/usr/include/linux -> /usr/src/linux/include/linux
とすべし というのを見たことがあったので鵜呑みにしてた
ちょっと調べるかな
0615login:Penguin
03/03/02 14:03ID:Oyof/yxmいて#ifdef KERNEL 等できりわけてあるの。で、glibcとkernelの開発が順調
ならここは同期するので、コピーしてもいいのですよ。
新しいカーネルで古いglibcを使うとかなると、だめになる状況が発生するの。
glibc はパッケージ化するときに glibc-kernelheaders として、その glibc
をコンパイルしたときに期待したカーネルのヘッダをとりこむので、どっちかっ
ていうとこっちを使ったほうが安全だけど、基本的にはlibcはカーネルと合せ
てつくらないとだめです。
0616login:Penguin
03/03/10 22:33ID:/SdozaOc〜 ファイルシステム／ボリューム管理機能の進化 〜
http://www.atmarkit.co.jp/flinux/special/kernel26/kernel26_03a.html
川o・-・）ノ ＜先生！こんなのがありました！
＿_/ / /
＼(_ﾉ￣￣￣＼
||ヽ||￣￣￣￣||
...||￣￣￣￣||
http://saitama.gasuki.com/saitama/
0618login:Penguin
03/03/17 21:44ID:7QyIeJjo〜 IPv6、UML、セキュリティ機能の統合 〜
http://www.atmarkit.co.jp/flinux/special/kernel26/kernel26_04a.html
0619login:Penguin
03/03/19 03:08ID:suPCGW2S0620login:Penguin
03/03/19 11:34ID:N7reRNVSこの本はKernel2.2用にかかれています。
2.2を学んだあと、2.4になって変更された部分などを知るのに適した
書籍などってありますでしょうか？
0621login:Penguin
03/03/21 00:19ID:DvPk6Xi8http://www.changelog.net/log/1999/special/wwol2.4/
0622Jet Charles
03/03/25 20:22ID:Px5e54WHとときどきpanicになってしまいます。再現性が低いのですが
構造はstruct {unsigned int spectrum[2048],int start,int end};
な感じです。
ポインタで渡すことにしたら問題は無くなったかに見えるのですが、
いまいちピンとしません。
C言語ではこういう配列わたしちゃいけないのですか？（仕様など）
or
カーネルではいけないのですか？（サイズなど）
ユーザスペースで動くテストプログラムはうまく走るので
バグ混入を恐れつつ開発継続中。
どなたかご存知の方がいればよろしくお願いいたします。
0623login:Penguin
03/03/25 21:03ID:fjRYSSzYカーネルスタックはそんなに容量ないです。
でかい領域が欲しければ、素直にkmallocしましょう。
0624名無しさん＠Ｅｍａｃｓ
03/03/25 22:11ID:7wu3YUNoカーネルスタック小さいからだめ。Cの仕様ではかまわない。
でもね。実際的にはだめ。コストを考えなさい。
0625Jet Charles
03/03/27 06:23ID:Kwn8SiQbおかげで不安は減りました。
スタックのサイズは同時にはしる全てのモジュールが
関わるにもかかわらず、OSが落ちるというのも考え
ものですね、、
0626login:Penguin
03/03/27 08:09ID:10DBd27vなんのためのオープンソースなのですか？このプロセスがあるから、
キミのような腐ったモジュールが排除されるのです。
lkmlでは自動的にスタックをたくさん使っている関数を列挙するツールや、
それで見付かったスタック喰いの関数の書き直しを精力的にやってますよ。
0627名無しさん＠Ｅｍａｃｓ
03/03/27 08:11ID:AAL7v3K2確かに、ユーザ空間のようにスタックを保護してくれると便利かもしれないの
ですが、OSだったりファームウェアの場合は必ず、ユーザアプリも多くの場合
は、スタックの量を、事前にちゃんと設計しないとだめです。
それに、残念ながら、Linuxではドライバは、スタックに限らず、どんな破壊
工作でもできるので、スタックだけ保護してもさほど意味ないのですよ。弱ー。
0628login:Penguin
03/03/27 13:25ID:mo6iAXITドライバでそういう事するのが、そもそも間違っているという説もあります。
>>627
カーネルとドライバが同じ権限で動いている限り、どのOSでも避けられない問題のような気がしますが。
0629login:Penguin
03/03/28 14:56ID:LjzZGjYj2.6からなんとかする模様
0630名無しさん＠Ｅｍａｃｓ
03/03/28 23:27ID:tgiw/vfZうん。つまり、カーネルとドライバが違う権限で動いているOSでは避けられる。
0631名無しさん＠Ｅｍａｃｓ
03/03/28 23:28ID:tgiw/vfZ0632山崎渉
03/04/17 12:11ID:PWISM87M0633山崎渉
03/04/20 06:09ID:X64WTq1+（ ＾＾ ）＜ ぬるぽ（＾＾）
0634login:Penguin
03/05/04 17:20ID:ide68tWq0635login:Penguin
03/05/06 20:57ID:/f1wWtEtにLinuxカーネルについての解析資料が移動したらしい。
0636login:Penguin
03/05/14 17:38ID:+1wC02Dwあるいはgccでガチガチ最適化カマしたやつとか。
0637ヽ(´ー｀)ノ
03/05/15 09:38ID:MQgHohK4Intelコンパイラは知らないけど、gcc で最適化するのなら自分でリビルドすればいいのでは？
イマドキのマシンなら30分くらいで終わるっしょ。
// 俺のじゃ丸半日掛かるけどなー
0638login:Penguin
03/05/15 20:15ID:tl6lLPOqそんな貴方にGentooLinux
（iccも使える、、と思うけど、そっちはよーしらん）
0639login:Penguin
03/05/15 21:50ID:fOOiJy16なぜCではなくC++？ なのかは置いておいて、
今のバージョンのintel C compilerだとLinux kernelがコンパイルできんので無理。
というか羊頭狗肉になっちまう。
次期バージョンでkernelがコンパイルできるようになったら
それを売りにするディストロも出てくるかもな。
gcc最適済ディストリは今は無き？stampede Linuxがやってたが、
gentooとかなら自分でできるだろ。
0640山崎渉
03/05/22 02:18ID:VfjbtMwi0641login:Penguin
03/05/24 02:05ID:pFXNmjMbソースのコメントに「これらのオフセットはハードコードされている．注意して扱うように．」みたいなことが書いてあるのですが．
0642login:Penguin
03/05/24 02:12ID:B4Q+JvDP忠告に従ったほうがいいかも。
どっかの地雷をふむかもしれないよ。（ｗ
0643login:Penguin
03/05/24 02:46ID:Ac66WbG3archによる。
アセンブラのコードで直接見ていることがある。
Cの方はオフセットがずれて困るところはないはず。
0644login:Penguin
03/05/24 03:01ID:B4Q+JvDPいぁ、ちょと見てみたんだが。
Cでtask_struct構造体ポインタに対してaddする個所があった。（ちなみにi386ね）
grepしてみたけど修正してできない量ではない。
けど、結構気をつけないといけないかも。
0645初めて
03/05/24 11:12ID:3ITeRmp+何度やっても
Uncompressing ... Ok,booting the kernel.
で止まってしまいます。
理由がわかりません。
なにかチェックする項目を飛ばしているのでしょうか？
2.4.20で起動するconfigからmake oldconfigで再度.configを作っているつもりなのですが。
これだけでの情報では原因を推測することは無理でしょうか？
OSはRedhat9.0で、再構築したいカーネルは2.5.69です。
どなたかアドバイスを頂けないでしょうか？
よろしくお願いします。
0646643
03/05/24 11:21ID:Ac66WbG3そんな所あったっけ？
しばらくi386依存部分は触っていないから、記憶が薄れつつあるなー。
>>645
おとなしく2.4.20を使う。
2.5.69はハードウエア構成によっては、そういう問題がおきます。
0647login:Penguin
03/05/24 14:44ID:im3d3bk6問題が起きたらデバッグしてください。2.5シリーズというのはそのためのものです。
0648644
03/05/24 15:13ID:PMIRyT6Tcopy_thread関数での以下の個所
int copy_thread(int nr, unsigned long clone_flags, unsigned long esp,
unsigned long unused,
struct task_struct * p, struct pt_regs * regs)
{
struct pt_regs * childregs;
childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long) p)) - 1;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ここ
0649644
03/05/24 15:31ID:PMIRyT6T>2.4.20で起動するconfigからmake oldconfigで再度.configを作っているつもりなのですが。
>これだけでの情報では原因を推測することは無理でしょうか？
>OSはRedhat9.0で、再構築したいカーネルは2.5.69です。
make oldconfigではなくmake mrproperからmakeしてみては？
0652645
03/05/24 19:30ID:3ITeRmp+make oldconfig
というのは、
そのフォルダにある、.configをもとにして足りない所を補い,新たな.configを
作成するというのであっているのでしょうか？
そのとき作成にしようした.configはoldとかにリネームして。
よろしくお願いします。
0653login:Penguin
03/05/24 19:43ID:b1IFVpVtlinux/scripts/Configure
読みなされ。
足りないところは聞いて来るはずだが。
>>645 の症状ってカーネル2.2の時の経験だと、
以降のboot messageがserialに出力されていた事があるけど、
これって2.4の話？ 2.5の話？
0654643
03/05/24 20:17ID:Ac66WbG3じゃなくて、お子さまプロセスのカーネルスタックの位置を計算しとるのですよ。
んで、計算した所に親の情報をコピーすると。
>>653
2.5はKconfigになってもーたので、scripts/Kconfig/confです。
挙動は変わらんが。
シリアルコンソールは、起動時に"console=〜"渡さないと有効にならないと思ったが。
0655644
03/05/24 21:10ID:PMIRyT6T((struct pt_regs *) (THREAD_SIZE + (unsigned long) p)) - 1;
これって親のtask_structからレジスタ情報を取得してるってこと？
で、
struct_cpy(childregs, regs);
親プロセスの現レジスタを子スレッドのレジスタにコピーして、
childregs->eax = 0;
childregs->esp = esp;
子スレッドのスタックを初期化して、
p->thread.esp = (unsigned long) childregs;
p->thread.esp0 = (unsigned long) (childregs+1);
親のスレッドスタックに生成するスレッドとその次のスレッドを設定して、
p->thread.eip = (unsigned long) ret_from_fork;
親スレッドの実行開始ポインタにcloneの戻り値を設定して、
savesegment(fs,p->thread.fs);
savesegment(gs,p->thread.gs);
親スレッドのセグメントレジスタを子スレッドに設定して、
unlazy_fpu(current);
struct_cpy(&p->thread.i387, ¤t->thread.i387);
ここらがよくわからんが。
ってこと？
0656645
03/05/25 00:25ID:XrZOXyc/0657643
03/05/25 00:59ID:Ix3J6K8u>>655
> ((struct pt_regs *) (THREAD_SIZE + (unsigned long) p)) - 1;
自分のスタックのアドレスを計算してるのです。
task_structのアドレス＝カーネルスタックの先頭アドレスなので、
そこにサイズを足してカーネルスタックの最終アドレスを求めて、
これからセットするデータの分だけ手前にもどす。
> struct_cpy(childregs, regs);
正解。
> childregs->eax = 0;
> childregs->esp = esp;
> p->thread.esp = (unsigned long) childregs;
> p->thread.esp0 = (unsigned long) (childregs+1);
大体正解。cloneの戻り値はeax
> p->thread.eip = (unsigned long) ret_from_fork;
自分に制御が回ってきた時、ret_from_forkから実行開始。
> savesegment(fs,p->thread.fs);
> savesegment(gs,p->thread.gs);
正解。
> unlazy_fpu(current);
> struct_cpy(&p->thread.i387, ¤t->thread.i387);
コプロのレジスタをコピーしているのです。
0658641
03/05/26 12:16ID:L9Tg8SeEありがとうございました．
皆さん凄いっすね．
0659login:Penguin
03/05/26 22:52ID:IXHBibv2CC kernel/timer.o
CC kernel/user.o
みたいな感じでなかなか新鮮
0660_
03/05/26 23:12ID:5mPv2JRl0661bloom
03/05/26 23:13ID:8OPOVfmH0662login:Penguin
03/05/27 00:44ID:Tx2/4y2mそのへんもだいぶ変わったからねえ…
make depなくなったし。Makefileの書き方も変わったし。
まあ、そのへんはどうでもいいんだけど、Kconfigの書き方が未だによくわかりません。
昔のドキュメント位詳しい物を早く書いてくれ。
0663login:Penguin
03/05/28 02:46ID:ZVfjfeIZうまく動作しません．
0664login:Penguin
03/05/28 02:55ID:ZVfjfeIZ以下がソースです．
#define MODULE
#define __KERNEL__
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/types.h>
#include <sys/syscall.h>
MODULE_LICENSE("GPL");
int (*real_setuid)(uid_t);
extern void *sys_call_table[];
int new_setuid(uid_t uid){
printk("system call was intercepted(setuid).\n");
return (*real_setuid)(uid);
}
int init_module(){
real_setuid = sys_call_table[SYS_setuid];
sys_call_table[SYS_setuid] = (void *)new_setuid;
printk("system call intercept(setuid) attached.\n");
return 0;
}
int cleanup_module(){
sys_call_table[SYS_setuid] = (void *)real_setuid;
printk("system call intercept(setuid) detached.\n");
return 0;
}
このモジュールをinsmodで組み込んでsetuidを実行する簡単なプログラムを実行してみましたところ，/var/log/messagesには意図した文字列が出力されません．
自分でもがいてみましたが，原因が分かりませんでした．どなたかご教授お願いします．
0665山崎渉
03/05/28 16:40ID:4u9ffZfOﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
0666login:Penguin
03/05/28 20:52ID:c/4bMbQpモジュールから上書きしていいものかどうか知らないけど、
int init_module(){
real_setuid = sys_call_table[SYS_setuid];
sys_call_table[SYS_setuid] = (void *)new_setuid;
printk("sys_call_table=%p,sys_setuid=%p,new_setuid=%p\n"
,sys_call_table,sys_call_table[SYS_setuid],new_setuid);
printk("system call intercept(setuid) attached.\n");
return 0;
}
みたいにして、予定通り書き変わっているか確認するしか無いでしょう。
0667login:Penguin
03/05/29 06:56ID:4nmgTop10668_
03/05/29 07:04ID:yrkPpXVA0669bloom
03/05/29 07:13ID:pdJrRzE30670login:Penguin
03/05/30 22:16ID:fuM2ZNep0671login:Penguin
03/05/30 23:09ID:XCgqHAqg0672直リン
03/05/30 23:13ID:t6UbAlau0673login:Penguin
03/05/31 03:10ID:DvCwdjkRi386系はMMUで実行権限の可、不可ってできなかったように
思えたけど（実際には読み込み権限と書き込み権限があって、読み込み権限＝実行権限）
実際、OpenBSDはどういう実装なんでしょうかね？
0674login:Penguin
03/05/31 10:26ID:pCrUKetPi386は実装中じゃなかったっけ？
思い付くのは、P落としておいて例外処理でごにょごにょ…って激しく遅くなりそう。
0675login:Penguin
03/06/02 04:39ID:CgaTSeAjありがとうございます．
やっぱりちゃんとアドレス自体は書き換えているようです．
で，他のシステムコールは正常にフックしています．setuidだけ（全てを確かめたわけではありませんが）が変なようです．
ライブラリを使わずに直接例外でsetuidを発行するとフックできました．
glibcのソースを見てみましたが妙なところは見あたりません．フツーのスタブのようです．
他のユーザID変更のシステムコールを使って発行しているのかな，とか思ったりします．
いずれ確かめます．
0676login:Penguin
03/06/02 15:53ID:Sji9M+OKRT signalを100%使い切るという結果がでてます。。。
loglotateでこーなるのか？？？
RT signalってなに？？
いろいろ探してみたのですが、なんでかわかりません。。。
だれかおしえてください。すみません。おねがいします。
0677login:Penguin
03/06/02 15:58ID:mduTnBfC0678login:Penguin
03/06/02 16:10ID:Sji9M+OKRT signal = リアルタイムシグナル と想定、
http://www.mmjp.or.jp/sunami/linux/kernel/ によると、
なんらか(ソフトウェア、ハードウェア)のシグナルの割り込み処理が
いっぱいいっぱい発生しているものと理解。
loglotateなどディスクをすごく使いそうな処理でこういう自体が
発生しているものと予想。
カーネルにとってRT signalのリミット100%を使い切るような処理
は日常茶飯事であって別に心配するこたぁないのか。
なんらかの対策をするべきことなのか、知りたいのです。
/proc/sys/kernel/rtsig-max が現在1024ですが、使い切っている
から安易に調整するべきものなのか、それとも運用を変えるべきなのか。。。
0679login:Penguin
03/06/02 17:20ID:tEGqhx7Sはずせば？
俺、リアルタイムで画像を記録するサーバ書いたんだが、slocateとかの
おかげで取りこぼしがでたからスクリプトはずしたよ。
0680login:Penguin
03/06/12 03:53ID:+ZjTB6j3試したのですが，唯一execveをフックするようにした時のみアプリケーションの起動で
segmentaion faultが起きます．アプリケーションが何も起動できません．
カーネルの中で起きているのでgdbが使えません．
皆さんはカーネルデバッグはどうしているのですか？
やっぱりUML+gdbとかですか？
それとカーネルモジュールのデバッグもUMLとかでやれるのでしょうか？
0681login:Penguin
03/06/12 08:32ID:9LpMpr/G0682login:Penguin
03/06/12 10:26ID:uPg3Erb9あの方法を使ったら、そうなるでしょうねえ。
(v)fork/clone/execveはアセンブラ使わないと無理でしょう。
デバッグは大体printkで。
kdbを使ってみたいなーと思う事もあるけど
2.5に対応していないので、使えない。
0683login:Penguin
03/06/12 11:20ID:+ZjTB6j3kgdbは確かデバッグを行う別のマシン（OS）が必要ですよね？
家は一台しかlinuxにさけるPCがないので，仮想マシンにするならUMLを使いたいです．
>>682
>あの方法を使ったら、そうなるでしょうねえ。
>(v)fork/clone/execveはアセンブラ使わないと無理でしょう。
なぜそうなるのでしょうか？
また，アセンブラでどのようにすれば実現できるのでしょうか？
というか，特定のシステムコールのフックは通常は
モジュールを使わずに直接sys_*の中を変更すべきなんでしょうが・・
0684682
03/06/12 16:28ID:uPg3Erb9kgdbなら、i386-elfを読めるgdbが動けばlinuxでなくても使えるはず。
んで本題。
arch/i386/kernel/process.cを読めばわかりますが、
system_callの所で作ったスタックフレームの構造に依存しているので、
スタックの状態を維持したまま呼んであげないといけません。
アセンブラなら、
call 自前の処理
mov 元のアドレス,%%eax
jmp %%eax
てなかんじで呼べば問題無いはず。
(i386のアセンブラは最近書いていないので参考程度に)
もう少し汎用的な書き方にならないかなーと思いますが、
CPUコンテキストが絡む話なので難しそうだな。
0685login:Penguin
03/06/13 02:15ID:Ntzc1lmuLinux2.5.64のソースにmachとかいうディレクトリがあるのだが、あれは一体なんなんだろうか。
ついでにもう一つ訊きたいのだがmach-voyagerとかいうのもあるのだが、あれは一体なんなんだ？
教えて君ですまん。
0686login:Penguin
03/06/13 08:39ID:EXw4iEhumachine architecture じゃないの？ m68kのmacとかsun3みたいに。
voyagerは確か昔のia32の超SMPマシン(といっても32くらい)、
って、linux/Documentation/voyager.txt があるやん。
0687685
03/06/15 16:25ID:TNnPLPxBThink!ミスター。あんた最高だよ。
0688login:Daemon
03/06/15 18:47ID:wufUnmIS＊BSDのカーネルについてかかれたものはないですか？
0689login:Penguin
03/06/15 18:48ID:vowloLzR0690login:Daemon
03/06/15 18:51ID:wufUnmIS0691login:Penguin
03/06/15 23:09ID:x0Igtqsi悪魔本
0692login:Penguin
03/06/16 03:19ID:P+dwJ3I8亀レスですが、script(1)というのもあります。
0693login:Penguin
03/06/16 04:49ID:kWhRIl9xありがとうございます．
ユーザプロセスのTSSが保存されたカーネルスタックにforkの場合はcopy_threadで親プロセスのものをコピーし，
execveの場合は search_binary_handler（合ってますか？）でTSSが保存されたカーネルスタックを初期化するので，
これらの(struct pt_regs型を引数を持つ)システムコールをフックする場合は，
フックした関数の中でsys_*を呼び出してはいけないのですね．
で，アセンブラで書くにしてもどうやってモジュールで呼び出せばいいのでしょうか？
自前の処理の関数へのアドレスはどうやって取得すればいいのでしょうか？
それとも/usr/src/linux/arch/i386/kernel/entry.Sのcall *SYMBOL_NAME(sys_call_table)(,%eax,4)
の直前にアセンブリコードを入れるということでしょうか？
できるだけオーバーヘッドを避けたいので，これをやるなら特定のsys_*の中で処理を記述したいです．
0694login:Penguin
03/06/17 00:03ID:JrPl/8fuそゆことです。
実際のコードは.cの中にインラインアセンブラで書くか、
別に書いてリンクすればいいのではないかと。
entry.Sをいじる必要はありません。
例のサンプルならnew_setuidをアセンブラで書けば目的は達成できます。
後はカーネルと関係なく、Cとアセンブラを混ぜる話なので、
その方面のスレで聞いて下さい。
#なんでシステムコールを書き換える必要があるのか謎ですが…
#libcでoverrideすれば間に合いそうな気もしますが。
0695login:Penguin
03/06/24 17:33ID:/u6LQEV0初代Linuxから、1プロセスがディスクI/O待ちしている間、他のプロセスが停止したり
しないはずですよね。...MINIXじゃないんだから（笑）
Linuxカーネル2.5 最新開発動向
http://www.atmarkit.co.jp/flinux/special/kernel25/kernel25b.html
|■プリエンプティブルカーネルサポート
| ：
|音楽を再生するときは、通常アプリケーションからオーディオバッファへ数ミリ〜数十ミリ秒
|間隔でデータを転送し、オーディオバッファにためられたデータが順次再生されていく。だが、
|次の音をバッファに転送しなければならない状態であるにもかかわらず、ディスクアクセスな
|ど、場合によっては数十ミリ秒程度の遅延時間がかかるシステムコールを処理してしまうと、
|その処理時間にCPUが引きずられる。
正しい説明は、こっちで合ってますか？（こっちは kernel2.6 だけど）
http://www.atmarkit.co.jp/flinux/special/kernel26/kernel26_04a.html
0696login:Penguin
03/06/24 21:10ID:lLx7L/ffその引用は2.4までのものでしょ?
2.4までは実行中のプロセスが完了するまで割り込めないと思うけど。
バッファにデータを転送する前にディスクアクセスするようにスケジュールされていたらそうなるんじゃない?
で、引用元には2.6ではカーネルプリエンプションが可能になるのでこういった事態を抑制できると書いてある。
プロセスA,B,C,DがA→B→C→Dの順でスケジュールされいて、Bの実行中にAが割り込みをかけたとする。
【2.4系以前】
Bの実行終了後に再スケジューリング。続いてAを実行する。
【2.5.4-pre6以降】
Bの実行を中断し、再スケジューリング。Aが実行された後でBが再開する。
最も優先順位の高いモジュールで他のモジュールのコントロールを行えば、
リアルタイムでI/Oをコントロールできるから組込みにも向いてると思ってるんだけど。
あってるかな?
0697login:Penguin
03/06/24 21:26ID:/u6LQEV0>その引用は2.4までのものでしょ?
ええ、そうです。
で、言いたかったのは、2.4以前だって、引用に書いてあるほどタコな動きは
してないでしょ、と。
2.4以前だって、disk I/Oを開始する時には、（preemptive ではないにしろ）
自主的にsleepして、CPUを他のプロセスに開放するから、ディスクI/Oの間、
他のプロセスが実行待ちになったりはしないでしょ、という意味なんですが。
0698login:Penguin
03/06/26 01:32ID:9kOqx0yKディスクI/Oという点に限れば697の言うとおりだが、
non-preemptiveだと、なかなかsleepしないシステムコールが
他のプロセスの足を引っ張ることは実際にあるように思う。
例えばsyncとか、多分ディスクI/Oというより、バッファ周りの
話なんだろうけど…
■ このスレッドは過去ログ倉庫に格納されています