Maybe I'm missing something, but the only case I found that required extra wineserver work was for handling asynchronous ReadFile requests (since these requests don't go through the ws2_32 path, see patch 6). Using ReadFile like that is technically something you're not supposed to do, but we all know that means that someone's done it anyway. For everything else (send, recv, select) the proposed technique just requires a check to see if IP_PKTINFO is enabled so it can throw out the packet if it doesn't match the socket's interface.
The kernel developers have made it clear that they're not going to do anything to change the situation (and even if they did, it wouldn't work under BSD or Mac OS X), so it seems to me like the change has to be in Wine. It would also be possible to override the appropriate calls by replacing the different dynamically loaded symbols, though doing so seems like an awkward approach since Wine is already meant to be a compatibility layer. I would really like to see this issue get resolved, so I'm willing to put whatever work into fixing this that's necessary to get it done right.
Erich Hoover ehoover@mines.edu
On Sat, Oct 10, 2009 at 2:31 AM, Alexandre Julliard julliard@winehq.orgwrote:
Erich Hoover ehoover@mines.edu writes:
The maintainer has pretty much "put his foot down" on the matter (several times actually, here's a nicer one): http://www.mail-archive.com/linux-net@vger.kernel.org/msg01306.html
This is rather embarrasing, but apparently I left server/protocol.def out
of
the patchset. I could have sworn I tested these patches on a clean git,
but
apparently I made a mistake. Is there any chance that this mistake is
the
reason for the rejection? The additional code in these patches is only utilized (sans a call to getsockopt) on UDP broadcast sockets that have
been
bound to a specific interface. According to the kernel devs, this
behavior
is what IP_PKTINFO is meant to do and that they have no intention of
adding
an additional feature that does exactly the same thing.
I don't think you can do that reliably in user space, at least not in the Wine architecture. You'd have to put all the network I/O in the wineserver, and performance would suck. The kernel devs objection would work if it could be done directly inside the app, but I don't see a way to do that cleanly inside the Wine network layer.
-- Alexandre Julliard julliard@winehq.org