Hi James,
On Thu, 13 Apr 2006, James Carlson wrote:
And what about the places where Linux simply gets it wrong?
At one point, we[1] were attempting to follow Linux in this area for
_exactly_ the reasons you suggest. There seems to be so much broken
on Linux, though, that to follow it unquestioningly would be foolish.
Agreed.
We must also look at what makes sense for Solaris.
I disagree with that, it has to make sense for /users/, imho.
For example, setting the destination address on output, as Linux
appears to do, is just senseless and wrong.
Ack.
I wasn't aware PKTINFO could be used for output on Linux. If you want to
strip it down to just setting the source (by index or by address - but
not both together ;) ), I'd agree with that. (*please* call it something
else though).
The symmetry argument is this: recvfrom() gives you the inbound packet
source, and sendto() sets the outbound packet destination. This new
feature gives you the inbound packet destination, and it thus must set
the outbound packet *source*. The intentional model is that most
applications can just take the bits from the receive side and copy
them over to the send side without having to look at them. As far as
the application is concerned, the bits are just a token representing
the peer.
Sounds good.
Why would you ever want to set the output packet destination address
to be the same as the original input packet destination address?
:)
I agree that we ought to be as compatible with others as we possibly
can, but if all of our friends jump off a bridge, I don't think we're
compelled to jump as well.
A better answer might be to help the Linux folks fix flaws here ...
a) Call this something else (to avoid Linux IP_PKTINFO clash)
I disagree. It has symmetry with the existing IPV6_PKTINFO.
Yes it does. Except there is code out there out there today that has
certain exceptions of IP_PKTINFO.
Calling this IP_PKTINFO on Solaris is going to be a PITA for any
codebase which today picks between IP_RECVIF and IP_PKTINFO at compile
time for received-interface information. Such code may not compile any
more if we introduce this, until its developers update their auto* (or
equivalent portability goo) tests.
Even when they do, it's going to be very confusing to users to have to
remember that IP_PKTINFO are completely different on the two platforms.
Ie, despite the symmetry with the IP6 version, please let's consider the
pain we'll cause to code that would be interested in this functionality
(which therefore likely are already using the Linux flavour). Let
pragmatism over-rule aesthetics on this please. :)
Even IP_PCKTINFO or IP_PACKETINFO would do. :)
Raw + IP_HDRINCL doesn't appear to set ifindex ...
Oops - I got it jumbled together with IP_{MULTICAST,XMIT}_IF. That plus
HDRINCL lets you do it.
Is it the intention to allow both ifindex and destination or source to
be set? Or just source, as per above comment? Just source on output
would be fine of course. Former case ought to require privileges -
denying its use to unprivileged applications (VoIP?).
I mildly agree with this, but for a different reason. IP_RECVIF and
IP_XMIT_IF provide decent control here. I don't know why Linux chose
to mix in the interface here as well.
Linux doesn't provide IP_RECVIF iirc. It's just informational in the
Linux case I thought though. (Linux doesn't have IP_XMIT_IF either).
regards,
--
Paul Jakma,
Network Approachability, KISS. http://quagga.ireland.sun.com/
Sun Microsystems, Dublin, Ireland. tel: EMEA x19190 / +353 1 819 9190
_______________________________________________
networking-discuss mailing list
[email protected]
