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.<br>
<br>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.<br><br>Erich Hoover<br><a href="mailto:ehoover@mines.edu">ehoover@mines.edu</a><br><br><div class="gmail_quote">On Sat, Oct 10, 2009 at 2:31 AM, Alexandre Julliard <span dir="ltr"><<a href="mailto:julliard@winehq.org">julliard@winehq.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Erich Hoover <<a href="mailto:ehoover@mines.edu">ehoover@mines.edu</a>> writes:<br>
<br>
> The maintainer has pretty much "put his foot down" on the matter (several<br>
> times actually, here's a nicer one):<br>
> <a href="http://www.mail-archive.com/linux-net@vger.kernel.org/msg01306.html" target="_blank">http://www.mail-archive.com/linux-net@vger.kernel.org/msg01306.html</a><br>
><br>
> This is rather embarrasing, but apparently I left server/protocol.def out of<br>
> the patchset. I could have sworn I tested these patches on a clean git, but<br>
> apparently I made a mistake. Is there any chance that this mistake is the<br>
> reason for the rejection? The additional code in these patches is only<br>
> utilized (sans a call to getsockopt) on UDP broadcast sockets that have been<br>
> bound to a specific interface. According to the kernel devs, this behavior<br>
> is what IP_PKTINFO is meant to do and that they have no intention of adding<br>
> an additional feature that does exactly the same thing.<br>
<br>
</div>I don't think you can do that reliably in user space, at least not in<br>
the Wine architecture. You'd have to put all the network I/O in the<br>
wineserver, and performance would suck. The kernel devs objection would<br>
work if it could be done directly inside the app, but I don't see a way<br>
to do that cleanly inside the Wine network layer.<br>
<font color="#888888"><br>
--<br>
Alexandre Julliard<br>
<a href="mailto:julliard@winehq.org">julliard@winehq.org</a><br>
</font></blockquote></div><br>