Hi Guys,
I am just a developing a virtual serial driver in UDMF. I want that all IOCTL commands, read should handled sequentially , i,e. processing one at a time.
#1. I know, it can be added a mutex lock/unlock in IO request handler. Is this a good method?
#2. Is there IO queue configuration settings make IO requests are dispatched sequentially to driver?
Thanks,
Prasanth
i thunk you need to read a lot more
i think you should start by understanding whether you device can be opened mutiple times or only once. in either case, can it be openedd for OVERLAPPED IO or only sequntial. whatever it can be opened for, how will your driver complete the IRPs it recieves?
then understand that even a single device that can be opened by multiple UM processes, and can pend multiple overlapped IOOPs can still provide the guranentee that they will be completed sequentually (from the point of view of when the IO manager recieved them).
IMHO a greatweekness in the design of Windows is that these IO calls must be serialized from the ‘outside’ and the true order cannot be reported from within the Kernel, but that problem has existed since NT 3.51
better designed UM processes that need to host network connections, should still plan to pend multiple read IOPs with buffes allocated in UM
I am just a developing a virtual serial driver in UDMF.
Why? The serial port is as old as I am, and I am very old. Surely there are better ways to interface to your clients.
I, too, am thinking you haven’t done any research on your own, because the documentation on I/O queues makes this all very clear from the start:
https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/dispatching-methods-for-i-o-requests
IMHO a great weakness in the design of Windows is that these IO calls must be serialized from the ‘outside’ and the true order cannot be reported from within the Kernel,
I don’t understand this statement at all. In a system with dynamic scheduling and multiple processors, I’m not sure how you would define “true order”? Would that be the first thread that calls ReadFile and executes one instruction… or the first one to get into kernel-mode in processing that system service… or the first one that builds an I/O Request Packet, or… ???
The fact of the matter is, in such systems there IS no “one true order” – You call ReadFIle, you get part of the way into that routine, you get rescheduled, somebody ELSE calls ReadFile on the same device, THEY get part of the way into that routine… Who’s “first” in the one true order?
Windows simply lays bare this fallacy. If you want order, it’s up to YOU to create it. Full stop. Any other solution is just an arbitrary ordering that some will praise and others will “endure.”
Peter
Peter
If you want to call ReadFile, and the ‘file’ itself already exists and so the order of completion of ReadFile requests makes no difference then there is no problem. But if the ‘file’ in question is a stream of data - as in the case of a TCP stream or in the case of many kinds of device supplied data, the order of completion matters, but cannot be controlled in any way due to thread pre-emption etc. a problem exists.
The choices suck. A single posed read per handle? – that can starve the producer or at least causes extra memory copies. Multiple posted reads per socket with a UM assigned sequence number assigned while holding a lock preventing other threads from issuing IO on the same handle?
So it does not seem so hard, but then consider what happens once a read completes. The thread that processed one needs to issue another so that the driver won’t starve. That’s where the real
problem happens
Michael
Which is why serial drivers typically operate in a buffered mode, pulling data from the device and storing it in a ring buffer until a reader can retrieve it. And then also depend on hard or soft flow control to block the transmission from the other end. This decouples the h/w side of read from the s/w side of read.
-p
It’s both more complicated… and more simple… than you’re making it sound. Devices and their drivers and their paired DLLs just need to be helpful… and not developed “the easiest way possible.”
Devices buffer data via DMA in buffer pools provided by the driver. No recopy needed. The driver just needs to use the device ring buffer a bit more cleverly than the typical “I set it up once at startup, and copy stuff to the user when it’s done.”
Or you DO the recopy. Small cost these days, really, unless we’re talking about really huge packets, in which case see above.
If the requirement is to serialize the data that’s returned from a device, then that’s what you need to do. The driver provides a sequence number on receive. The app (or a DLL paired with the driver) reorders the data as required.
But this is rarely necessary. A single thread picking off one read completion at a time will typically get the job done.
Peter
Hi,
I had gone through “https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/dispatching-methods-for-i-o-requests” and knew that sequential, parallel, and manual queues are available.
I was double checking on this mechanism.
Thanks for> @Tim_Roberts said:
I am just a developing a virtual serial driver in UDMF.
Why? The serial port is as old as I am, and I am very old. Surely there are better ways to interface to your clients.
I, too, am thinking you haven’t done any research on your own, because the documentation on I/O queues makes this all very clear from the start:
https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/dispatching-methods-for-i-o-requests
I had gone through this msdn page and thought of doing a double check on the approaches. Thanks you very much for the comments.
The reason why i am using serial port is that application can ONLY use serial port.
Thank you all!
Devices and their drivers and their paired DLLs just need to be helpful… and not developed “the easiest way possible.”
The driver just needs to use the device ring buffer a bit more cleverly than the typical “I set it up once at startup, and copy stuff to the user when it’s done.”
Post of the month!
– pa