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

[Vibhav Pant (＠vibhavp)]

On Sat Aug 31 17:49:29 2024 +0000, Rémi Bernon wrote:
> > If you're referring to the new RPC structs, I understand. That being
>
> said, my one concern is whether stuffing the file path into `dbch_data`
> could potentially break some code out there that uses `dbch_size` to
> guess which event is being sent (something like `if (n->dbch_size ==
> (sizeof(DEV_BROADCAST_HANDLE) + sizeof(BTH_RADIO_IN_RANGE)`). It is an
> extremely stupid way to check for the event, but I'm not sure whether
> someone doing this can be safely discounted. I'll write some test code
> to see if this can be done on Windows to begin with.
> But as far as I understand, as `plugplay_send_event` is completely
> non-standard, these structs are only ever sent internally? So you don't
> really need to bother about abusing some fields or size for the internal
> notification, you even considered using custom structs which you would
> convert back and forth on both sides.
> Simply put whatever you need in the DEV_BROADCAST_HANDLE struct you
> send, using any unused field, or some other way, to put the device path
> in it if you need that, and just make sure you fix it up to a correct
> DEV_BROADCAST_HANDLE struct before calling the notification callback?
> Although I don't feel like it's even worth it you could even use a
> custom DEV_BROADCAST_HDR based struct, or extend DEV_BROADCAST_HANDLE
> with a custom derived struct which has an explicit device path, for the
> internal messages. I just don't think you need to change the
> DEV_BROADCAST_HDR base, or change the DEV_BROADCAST_DEVICEINTERFACE code
> in any significant way for this.

I have re-written this series to use `dbch_reserved` and implement `IoReportTargetDeviceChange` here, so I'll close this MR: https://gitlab.winehq.org/wine/wine/-/merge_requests/6437