※ 引述《ephesians (ephesians)》之銘言： : ※ 引述《ggg12345 (ggg)》之銘言： : : 這是這個討論題的重點嗎 ? 答案是很簡單也很容易知道, 但可不必回答! : : 這種攔截 system call 提供額外通用功能的絕招, 全台灣都是源自於同 : : 一個起源 ! 反對這種方法的理由也點得夠白了, 各有優缺點, 何況這也 : : 不是絕對必要或不可或缺的方法. : 這當然是重點! : 你不可能要求每一位同學都試著寫一份核心, : 即使你是發展MINIX的那位教授,也不可能讓每位同學都很會寫OS基本功能. : 但是, : 教同學怎麼用system call以達成比一般程式更進一步與OS互動,行不行!? : 當然可以啊! : 還有,這位老師,我要糾正你一個錯誤的觀念, : system call並不是額外提供的功能,也不是外掛, : 而是OS提供外界與底層溝通的介面. : System call明明是OS本身具備的東西!!! : 我真不敢相信你怎麼能說 "不該用system call" 這種奇怪的觀念. : 假設是這樣,只要你想寫一點靠近底層的程式, : 不能用system call,意味著你必須直接改寫核心, : 誰那麼有本事? : 如果是Windows的系統程式,核心程式碼拿不到, : 是不是要叫一堆學生自己搞反組譯啊? : 學生不會寫,老師又只會出嘴砲,這種痛苦你是知道了逆? : 又,OS提供system call介面,也表現出模組化與程式分工的精神, : 這不是跟軟工的理念不謀而合嗎? =========== 把問題講清楚, 你要攔截與擴充 system call 還是只是要 呼叫 system call ? 誰跟你說不該用 system call ? 高階語言用的 system call function 多數被包含在 Library 裡面. 某些 AP 發展工具則提供 API 也都是 Library call 形式. 要用 register 傳參數的 system call 只有用組語最方便, 但多數人寫程 式少用組語. " 攔截 system call " 這是早期台灣某校的密笈, 多數的 AP 使用 系統資源都是透過 system call , 如果在 system call 入口之前, 還回之後, 就被堆高插入一段 "擴充程式" 或 "擴張解譯" 的程式, 就能銜接舊有 AP 加入新增的功能. 這種技術在 UNIX 是包抄 library 中的 system call function 加以改裝, 要 AP 在呼叫時, 換個名稱, 沒有 AP source 是改動不了, 這技術一般稱為 wrapper function. 攔截 system call , 如果是高段的做法, 可不必依賴修 改 source, 而是銜接在 system call 入口之間, 因此可以做到 binary program 相容. 這種技術就是產生一種功能可以適用在很多不同的 AP 上都能使用. 某些做軟工的反對使用 "攔截 system call" 這種技術, 就因為這是 接枝法, 接枝法會造成排他性的互相攻伐, 喜歡的就用此絕招上陣. 某些做軟工的不喜歡 "攔截 system call" 做功能擴充. 這些不喜歡 的人就是強調要 "純軟體". 這是某類搞軟工者的願望與需求. --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.1.146