Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.

[Rémi Bernon]

On Fri Aug 30 18:00:21 2024 +0000, Vibhav Pant wrote:
> > Maybe we can avoid sending the paths every time by moving the
> > filtering to plugplay, adapting the interface a bit for this. There
> > could be additional methods to register paths / get plugplay handles in
> > return, and later use these handle as device handles.
> > Perhaps, but wouldn't this make both plugplay service, and the
> > notification code sechost/service.c a lot more stateful as a result? Re:
> > device handles, if you're referring to the `dbch_handle` field in
> > `DEV_BROADCAST_HANDLE`, we already get that from the user using
> > `RegisterDeviceNotification`, and the current code just uses them for
> > sending notifications.
> > I don't think adding custom structs is justified at this point, especially as it requires rewriting large parts of the code in multiple modules at the same time.
> Perhaps, but wouldn't this make both plugplay service, and the notification code sechost/service.c a lot more stateful as a result? Re: device handles, if you're referring to the `dbch_handle` field in `DEV_BROADCAST_HANDLE`, we already get that from the user using `RegisterDeviceNotification`, and the current code just uses them for sending notifications.

Fwiw I'm fine keeping the paths, and using the `reserved` field to describe them. I was just considering additional improvements but this specifically doesn't need to be done now.

However, passing process-private handles around to other processes and later getting them back looks wrong. What happens if you register for notification on a handle then close it right away? Does the notification keep firing with the old handle value? It seem surprising and it would be a nice thing to test for instance.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80567