Hi,
There are many discussions in this thread. I add my 2-cent worth of opinion.
I strongly dislike using event notification from driver to application
except in the simplest cases where either you don’t need serialization for
message passing at all or the penalty to you is small if you enforce total
serialzation that do not allow concurrence.
The problem always lies the complexity involved in sychronization between
threads in user mode and kernel mode of accessing the messages of the
notifications. If multiple events could happen simultaneously, in other
word, the kernel driver has multiple messages to notify your user mode
application, it needs to queue the message in someway, and after user mode
application consumes the message, it needs to dequeue the messages. There
are several ways doing this using shared memory between kernel mode and user
mode, including using memory mapped file or kernel mode allocate memories.
You can quickly conclude that you need several kernel mode/user mode
crossing to accomplish a single message delivery that may include using
mutex to serialize the access the message queue, which one cannot do at
dispatch level, and allocate/dealloacte memory for the message, which
depedning your message memory allocation need, may not always possible to do
it at dispatch level.
Comparing what you have to do there, hanging IRP looks much better. It
requires much less kernel mode/user mode crossing and no sychronization and
memory allocation/deallocation hassles between kernel mode and usr mode. You
may need a IRP queue in kernel to deal with concurrency issues in half
duplex type of communication.
The most efficient way to do this is to use extended native NT service
instead of ioctl. Please take a look at Winsock 2 WSAEventSelect and related
functions as a blue print for your implementation. However, there is only
undocumented way to roll your own native NT service and there comes with
compatiblity issues and there are always the possiblity that you step on the
toe of others who try to do the same thing or the other way around (See
Undoucmented xxxNT) and if that happens, it surely leads to a BSOD.
I call on Microsoft to allow kernel developer to be able to post thread
message to user thread (through ETHREAD object).
Or provide controlled way to roll ones own native NT service to eliminate
aforementioned problem, something like
int RegisterNativeNTService(…); (something CallNativeService(ordinal,
scurity_descriptor, … ) may also need for completeness)
where the return value is the ordinal number that we can used in issuing INT
2E or SYSENTER without worrying that someone else happen to choose the same
ordinal number or one of the Microsoft one if the OS is upgrade to new
version or a new service pack.
By using the controlled way like those I mentioned above, Microsoft can
allow only WHQL digital signed extended Native Service to be installed in
its future “secured” OSes.
Thanks.
Bi Chen