俺想请问一下关于驱动程序和进程的关系?

请问:当我们的应用进程想从一个设备中读数据时,它调用ReadFile(),进入了核心,再通过I/O管理器向驱动程序发IRP,驱动程序再完成相应的动作.
     俺要问的是:当驱动程序执行时,这个调用进程是继续执行呢?还是阻塞呢?即,驱动程序是作为进程的一个模块来运行呢?还是作为一个单独的进程或线程和应用进程进行交互?
                          谢谢!

程序可能继续执行或阻塞，这是你在调用readfile时指定的。去冬在系统京城中被执行，不是应用进程的模块。

谢谢！那么也许还有一个问题： 驱动程序是作为系统的一部分去运行的吗？什么时候运行？ 是否可以进行调度？

老兄，你是想让我吐血呀，我现在被同步问题折磨得不行了。驱动是作为系统的一部分运行，什么时候运行要系统说了算。驱动是一些可调用的程序块，该调哪个的时候，系统自然会调。在驱动执行的时候，可能发生线程或进程的切换。

谢谢你的回答！同感同感触，俺也是苦于同步问题久也。有时间再来请教
不过，俺现在还得接着上面的问题问：那么，驱动程序是否作为核心代码的一部分运行的？ 俺好象记得，在核心代码运行时，是不能进行切换的？

呵呵，关于这个，恐怕得看看IRQL

弱弱的一问：
   楼上的老兄，请问IRQL是什么东东？
   谢谢！

IRPL就是传说中的中断优先级。在系统进程中，只有在IRQL等于0时，系统会发生线程切换，如果大于0，就不允许更低的IRPL抢先运行。

老兄,俺给弄糊涂了. 你所说的IRPL是属于系统进程吗?俺只记得核心根据线程的优先级去调度线程,和中断优先级有什么关系?

建议你到这里看一篇文章，讲的挺清楚的哦

http://sys.xiloo.com/documents/irql.htm

另外，你提到的这些在inside win2000里面都有讲解

谢谢你的提议和好文章.俺花了一天时间去看好象有点心得.就IRQL,俺感觉是为在核心中运行的例程之间的关系而设值的.在核心中的例程都可以通过程序员去设置一个合适的IRQL.现在,假如你愿意俺想和你讨论一下驱动程序和IRQL的关系.下面这段话你看对不对:
       1.当俺们在应用程序调用一个ReadFile()函数时,发生了软中断系统进入了核心,开始访问设备,取得了数据后,方能返回应用程序,接着执行ReadFile()下一条语句.要是数据没有取到这这个应用程序就阻塞在这条语句上.当时间片完成了,此时系统将驱动程序的当前例程的IRQL和定时器的进行比较,大于就仍然阻塞,小于就开始调度另一个线程执行.不知道这样说对否?
       2.要是这样说法是对的.那么,要是俺在执行了ReadFile(),不关心知道设备是否取得数据,想接着执行下一条语句.这时该怎么办俺也想过可在驱动程序中设置同步语句,不过,那时应用程序仍然是阻塞的有没有更好的办法呢?
             谢谢!
  

使用异步读是不会阻塞的

没错，打开文件读写可以选择同步，异步方式的，决定阻塞与否，事实上用户程序和部分核心驱动代码都在PASSIVE_LEVEL上跑，在同一个IRQL，少数核心例程如StartIo才运行于DISPATCH_LEVEL

是的，打开文件读写是可以选择同步，异步方式。但俺想知道的是问题中的原理。在不选择阻塞方式时，当进入内核执行，假如驱动程序没有完成应用程序所交给的任务，这时会回到应用程序的下一条语句接续执行。那好，俺想知道什么时候，什么情况下驱动程序会接着执行未完成任务？就俺所知，在CPU调度的是线程或进程，而不是例程。驱动程序一般情况下是不能单独作为线程或进程来有机会去运行的，也就是说，不进行系统调用，是无法启动驱动程序的）
             以上说法不知道对否，请各位大侠指点！！

你好，就我的理解应该是这样的，

1 应用程序调用ReadFile
2 ReadFile调用文件系统驱动的功能，文件系统驱动（FSD）的分派函数运作，创建IRP发送下去
3 IRP到了磁盘类驱动，磁盘类驱动的分派函数对IRP进行处理，包括生成Srb等，并且将请求发送到下层：
      port/miniPort驱动
4 miniPort驱动操作硬件，作DMA/PIO/...把数据放入buffer
5 返回，一层一层的进行，调用completion routine，最后交到文件系统手上
6 完成

其中在请求发出到回调到最后一个completion中间，对于非阻塞，应用程序可以撒手干别的事情，和别的
PASSIVE_LEVEL代码并行，但是在几个环节，比如miniPort的startIo、中断服务程序、等，由于其IRQL高
（>=DISPATCH_LEVEL），那些低IRQL的代码，显然包括你应用程序的函数和上层驱动的大多分派函数，
运行在PASSIVE_LEVEL上的，将无法运行，这个过程和任务调度没有关系。

  谢谢你的解答.你所说的俺也能理解.和俺在书上看的一样但是有这么一段话俺觉得值得商洽:
  .......其中在请求发出到回调到最后一个completion中间，对于非阻塞，应用程序可以撒手干别的事情，和别的PASSIVE_LEVEL代码并行，.......
  在俺学操作系统时,好象记得老师说过:两段代码要并行执行(在单处理机上),只能通过这两段代码在不同的进程或线程中去实现.现在,你说应用程序可以\"撒手干别的事情\",也就是和你所说的1,2,3,4步骤是并行执行的. 但进过上面的讨论大家已经排除了这几步是进程或线程的可能性,那么在WINDOWS2000中是怎么样实现的这几步和应用程序的并行的呢?

这个问题是这样：
接受你请求的驱动一般不会直接读写端口，他会把IRP接着向下发。在向下发的过程中，他返回，也等待此IRP被完成。IRP内有一个完成列程，在IRP完成后，此历程就会被调用，驱动会回到相应的点继续操作。也就是说，在他向下发以后，完成列程还没有执行时，你的readfile可以接到控制。

你的意思是说应用程序和核心例程可以并行运行?那么当返回应用程序了应用程序当然继续执行调用函数的下一条语句.那么,你所说的\"......IRP内有一个完成列程，在IRP完成后，此历程就会被调用，驱动会回到相应的点继续操作......\"也就是这个例程是和应用程序是并行执行的关系,那么这个例程是被什么样的机构调度的呢?肯定不是线程调度机构

Is it the question of context of driver routine ?
I want to known when the context is user thread and when is kernel thead too.