major函数的重入问题

  IRP_MJ_READ,IRP_MJ_WRITE,IRP_MJ_DEVICE_CONTROL等对于的major函数会不会重入，就是前面一个read函数还没有返回，下一个read又已经来了。会不会有这种情况。我跟踪debugprint记录，好像IRP_MJ_READ,IRP_MJ_WRITE对应的函数好像没有重入现象，但是IRP_MJ_DEVICE_CONTROL对应的函数好像会。各位大侠觉得如何呢？还要假如会重入，怎么处理比较合适？谢谢各位。

Let me try to answer your question.

I think "重入" doesn't simply mean "前面一个read函数还没有返回，下一个read又已经来了". For example a cached I/O may trigger paging I/O which should be completed before cached I/O. Also Cache Manager or Memory Manager could send down multiple IRPs in a short time which is simply parallel programming issue.

So "会不会重入" totally depends on how a FSD intercept IRPs. For example in MJ_CREATE, if FSD tries to open a file internally, there could be "重入". But if a FSD doesn't want to open any files internally in MJ_CREATE routine, there won't be "重入" at all.

By the way, I don't understand why your Device IO Control could have "重入" problem. Could you please let us know what do you do in MJ_DEVICE_CONTROL?

首先感谢michaelgz兄的回答，我做的不是fs而是块设备驱动的功能驱动（functional driver），里面不太涉及cach和memory，也不是说不涉及。read和write都是读写块设备。deviceiocontrol里面涉及到对一个配置文件的读写。配置文件也是在块设备上，我把他说成一个文件，严格来说不是文件，只是块设备中一个专门区域。这个文件还比较大，读写也比较频繁。我想知道的会不会重入。“前面一个read函数还没有返回，下一个read又已经来了”，这个只是我把重入简单解释一下。

下面是引用michaelgz于2005-07-25 10:34发表的:
Let me try to answer your question.

I think "重入" doesn't simply mean "前面一个read函数还没有返回，下一个read又已经来了". For example a cached I/O may trigger paging I/O which should be completed before cached I/O. Also Cache Manager or Memory Manager could send down multiple IRPs in a short time which is simply parallel programming issue.

So "会不会重入" totally depends on how a FSD intercept IRPs. For example in MJ_CREATE, if FSD tries to open a file internally, there could be "重入". But if a FSD doesn't want to open any files internally in MJ_CREATE routine, there won't be "重入" at all.
.......