> 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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80535
On Fri Aug 30 05:47:12 2024 +0000, Rémi Bernon wrote:
> > @rbernon I'm okay with using reserved as an offset to pass the device
> path, but we'd still have to pass it for every message for filtering. I
> didn't want to utilize `reserved` mostly out of caution, if it ever
> turned out to be that the field did have some undocumented semantics
> after all.
> 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.
That seems like an awful lot of complication just to avoid defining a structure?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80533
This series is motivated by performance requirements for GetExtendedTcpTable, especially the tables that require owner PIDs. In the worst case, the existing code scans all /proc/\<pid\>/fd directories for all Wine process for every socket, and may repeat the entire scan up to 5 times if the number of connections outgrew the buffer. With esync, processes can easily have hundreds of entries in /proc/\<pid\>/fd. And, in certain environments, reading the files under /proc can be very slow; I've seen GetExtendedTcpTable take almost 2 seconds to complete.
Some applications (GOG Galaxy, Steam) use the TCP table to check that incoming connections to local services are from a set of whitelisted processes. It's possible for the GetExtendedTcpTable to take longer than the timeout on the socket, which results in failed communication between the client and service.
wineserver knows about all sockets and what process they belong to. The only missing information needed for GetExtendedTcpTable is the state of TCP sockets, which is recoverable from getsockopt(TCP_INFO).
I've added a function in server/handle.c that enumerates all handles of a given type in all processes. The new server calls use that to find all sockets and return the needed information.
Apologies for commit 3 being large. I couldn't think of a way to split it without introducing dead code.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6399
The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`:
* `BluetoothSdpEnumAttributes`
* `BluetoothSdpGetContainerElementData`
* `BluetoothSdpGetElementData`
* `BluetoothSdpGetAttributeValue`
--
v11: bluetoothapis/tests: Add test for BluetoothSdpEnumAttributes and BluetoothSdpGetAttributeValue.
bluetoothapis: Implement BluetoothSdpGetAttributeValue.
bluetoothapis/tests: Add unit tests for BluetoothSdpGetContainerElementData and BluetoothSdpGetElementData.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6402
The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`:
* `BluetoothSdpEnumAttributes`
* `BluetoothSdpGetContainerElementData`
* `BluetoothSdpGetElementData`
* `BluetoothSdpGetAttributeValue`
--
v8: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6402