※ 引述《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