→ jerry031181: 資料在memory 可是OS不知道阿 所以 才有IO complete 09/28 01:11
→ jerry031181: 去通知OS 而那段就是處理interrupt的routine 09/28 01:12
→ jerry031181: 我是覺得那不是device driver啦 應該是io subsystem 09/28 01:14
推 goldflower: 看起來應該是 如果有多個io 那這樣會同時配置多個 09/28 02:17
→ goldflower: buffer 但是io完成時系統還不知道要從哪個buffer去抓 09/28 02:18
→ goldflower: 所以要device driver把這部分的訊息再通知給系統 09/28 02:18
→ goldflower: 而且因為系統要透過device driver才能知道io的狀態 09/28 02:19
→ goldflower: 所以才會有這一步 然後系統收到io狀態後就能根據這個 09/28 02:20
→ goldflower: 資料決定哪個process能繼續執行之類的 09/28 02:20
→ goldflower: 以上是我腦補的 念os感覺好像要一直幻想...XD 09/28 02:22
→ jerry031181: 我是覺得是interrupt handler generate interrupt給 09/28 10:42
→ jerry031181: OS 然後根據收到的interrupt 去查中斷向量表 去執行 09/28 10:43
→ jerry031181: ISR(取回buffer 中的data）然後再 回復interrupt前 09/28 10:45
→ jerry031181: 暫停的process 而那個需要data的process則是被移到 09/28 10:46
→ jerry031181: Ready queue 等下次他取得cpu時就能使用memory中 09/28 10:47
→ jerry031181: 的data 09/28 10:49
→ forever3580: 我有在網路上查了一下 我查到的資訊是說 interrupt h 09/28 23:22
→ forever3580: andler包含interrupt vector跟 ISR欸 所以我覺得devi 09/28 23:22
→ forever3580: ce driver應該就是單純把資料傳送完的結果告訴kernel 09/28 23:22
→ forever3580: 然後interrupt的訊息應該是從device controller發出 09/28 23:23
→ forever3580: 的 應該不是interrupt handler吧？ 09/28 23:23
推 goldflower: 所以如果是這個說法的話 似乎在device driver return 09/28 23:32
→ goldflower: 之前根本也不會通知kernel 因為這兩個直接在handler裡 09/28 23:33
→ goldflower: 可以做完 若是如此的話恐龍書那個圖的確就是整個流程 09/28 23:34
→ goldflower: 我說這兩個是指查vector和ISR運作的部分 09/28 23:35
→ goldflower: 這樣子的話可以減少一次和kernel的溝通 感覺好像比較 09/28 23:36
→ goldflower: 有效率? 09/28 23:36
→ forever3580: 嗯嗯 我的想法就是這樣～～ 09/29 15:36