Client-server manner communication with driver

Hello! I want to impl full duple communication with driver and user space. What modern communication pattern advise : Client-server, messaging service in high level lang approach? Please help to make understanding and choice

The answer is always the same. Use inverted call. In most cases, what you need is a request/reply protocol from user-mode in. That’s the normal ioctl situation. If you sometimes need comms from the driver out, you have the application submit a couple of ioctls that you keep pending in the driver forever. When you need to send something out, you pop an empty request, fill it, and complete it. Easy, reliable, secure.

The answer is always the same. Use inverted call.

Well, you’ve got to update your “scratched CD” once in a while ( approx.once in around 12-15 years or so). The answer USED to be the same, but now there is a new “best practice”( known as a “Big Honkin IRP”) around…

Anton Bassov

No, Anton. Just… no.

Peter

generall best practice is still not to use a long lived IRP to implement shared memory. this long lived IRP addesses the cleanup issues associated with legacy shared memory approches, but not the signalizion issues. when jitter performance is critical, good programmers can do this in a way that is better than the built in methods, but otherwise don’t touch this by my advise

Exactly. Bug Honkin Hangin is for those situations where people (insist they) want a shared memory solution, because it helps avoid “the cleanup problem.”

Best practice for client/server stuff is absolutely, positively, still inverted call.

Peter

No, Anton. Just… no.

Please note that I am arguing, as usual, only against “ALWAYS” part. More on it below…

Best practice for client/server stuff is absolutely, positively, still inverted call.

For example consider the scenario when data rate is high. A “Big Honkin IRP” seems to come in handy in this situation, right.

To make it even more interesting, these two approaches are not mutually exclusive. After all, if you share a buffer you still have to indicate data availability somehow,right. This is where the inverted call may come into the play even if you are using a “Big Honkin IRP” approach.
If you compare it to signaling an event, its extra overhead is simply negligible, but it seems to be much more convenient if youlook at the whole thing from the app developer’s perspective.

Anton Bassov

To make it even more interesting, these two approaches are not mutually exclusive.

Well, finally you’ve said something I can agree with.

Inverted call does indeed combine nicely with shared memory, as a signaling/coordination method. The I/O manager is nicely optimized and you can do some pretty cool things…

Peter

Guys, where I can read info about or see impl for “big Honkin’ Hangin’ Request” design pattern?
Thnx!

Described thusly by Mr. Roberts in May of last year:

The correct design would be to have one METHOD_xx_DIRECT ioctl where you pass the buffer, then keep that buffer pending in a manual queue for the life of the need. That way, the I/O manager takes care of the mapping and validation. You can follow up with a buffered ioctl to trigger whatever I/O operation needs to use the buffer. When you’re done, you complete the request.

Peter

Peter, thank you for much! Maybe I can see some implementation of this (big Honkin’ Hangin’ Request) approach?

I think you are missing the point. You don’t want an example of a design pattern that you should not be using.