Jackal
驱动牛犊
驱动牛犊
  • 注册日期2001-09-20
  • 最后登录2001-12-12
  • 粉丝0
  • 关注0
  • 积分0分
  • 威望0点
  • 贡献值0点
  • 好评度0点
  • 原创分0分
  • 专家分0分
阅读:1790回复:3

关于share IRQ的问题,几位大师如是说。

楼主#
更多 发布于:2001-10-30 12:34
我去comp.os.ms-windows.programmer.nt.kernel-mode这个新闻组问了一下有关share IRQ的问题,几位大师的回答令我茅塞顿开。其实问题的答案很简单,这里没人回答是不是大家误解了我的意思。

下面我把大师们的回答列出:

Doug Haigh:
Look at te 9th parameter of IoConnectInterrupt - ShareVector


Walter Oney:
You probably don't need to do anything at all. Just be sure that yourISR returns TRUE if your card generated the interrupt and FALSE if not.

Stephan Wolf:
Interrupt sharing, in general, ie. not an OS-dependant issue (same in
Windows, UNIX, NetWare, whatever), follows the same rules:

- An interrupt is requested by (at least) one of the devices that
share the same IRQ line.

- The "real" ISR of the OS is invoked (at some very high priority).

- "Real" ISR calls all driver ISRs for this shared interrupt and asks
each of them: "Has your device requested an interrupt?"

- If a driver determines its device has actually requested an
interrupt, it disables the device's IRQ line and returns TRUE.
Otherwise, it returns FALSE.

- If TRUE is returned by a driver's ISR, the OS schedules some
deferred interrupt processing handler for later execution (at some
lower priority).

- The OS may or may not ask all drivers or it may stop as soon as some
driver's ISR returns TRUE.

- If none of the driver ISRs returns TRUE, this is called a "spurious
interrupt". (People who use Novell NetWare have probably seen such
error messages.)

- OS leaves "real" ISR.

- Task/thread scheduler/dispatcher (many names - same purpose) invokes
deferred interrupt processing handler.

- Deferred interrupt processing handler handles the interrupt and
re-enables its device's IRQ line.

The actual implementation of interrupt handling may vary on different
OSes, but the overall rules are the same. (Not speaking for DOS,
though.)


Spiro Trikaliotis:
scheduler and dispatcher are two different things!

The scheduler *selects* ("schedules") a thread which is put to run
state ("dispatched") later by the dispatcher.

There might be OS where a combined scheduler/dispatcher does both, but
on NT (and RT-Linux, at least; I don't know about Linux itself), you
have both separated from each other.

Viscarola/Mason ("Windows NT device driver development", p.112) state
that with NT, the dispatcher resides inside the kernal while the
schedules is part of the subsystem, thus allowing every subsystem to
implement its own scheduling policy.


还有很多,我的问题在这个新闻组引起了一番讨论,呵呵。
Jackal
Jackal
驱动牛犊
驱动牛犊
  • 注册日期2001-09-20
  • 最后登录2001-12-12
  • 粉丝0
  • 关注0
  • 积分0分
  • 威望0点
  • 贡献值0点
  • 好评度0点
  • 原创分0分
  • 专家分0分
沙发#
发布于:2001-11-01 12:50
        嘻嘻。
Jackal
KDriver
驱动中牛
驱动中牛
  • 注册日期2001-06-09
  • 最后登录2008-09-13
  • 粉丝0
  • 关注0
  • 积分0分
  • 威望0点
  • 贡献值0点
  • 好评度0点
  • 原创分0分
  • 专家分0分
板凳#
发布于:2001-11-01 15:08
怎么去这个新闻组,老兄?
“萎软”,是Microsoft的小名!
Jackal
驱动牛犊
驱动牛犊
  • 注册日期2001-09-20
  • 最后登录2001-12-12
  • 粉丝0
  • 关注0
  • 积分0分
  • 威望0点
  • 贡献值0点
  • 好评度0点
  • 原创分0分
  • 专家分0分
地板#
发布于:2001-11-02 15:00
news.bentium.com

[编辑 -  11/14/01 作者: Jackal]
Jackal
游客

返回顶部