(usagi-users 03417) Re: Any particular reason that IPV6_TCLASS/IPV6_RECVTCLASS is not implemented?

[David Stevens <dlstevens@xxxxxxxxxx>]

"Peder Chr. Norgaard" <Peder.Chr.Norgaard@xxxxxxxxxxxx> wrote on 
06/22/2005 12:15:31 PM:

> On Tue, 21 Jun 2005, David Stevens wrote:

> But - do you have any opinions on the other issue I raised - the
> transition issue?  I will probably have to hack a solution within my
> project - there I need packages right here and now (such as quagga and
> iputils) that are run-time independent on whether the kernel contains 
your
> patch or not - and to me that says, "use a /proc entry to detect the
> semantics".  If I could design and test that solution so other people
> might use it, everyone would profit.

        The basic problem is that the new API uses the same
option names with different semantics. But you can detect the
difference and code to work for either one fairly easily.
Source like this should work with either API (for receive
side) (untested, so don't mind syntax :-) ):

/* turn on PKTINFO recvmsg control messages */
        on = 1;
#ifdef IPV6_RECVPKTINFO
        if (setsockopt(s, SOL_IPV6, IPV6_RECVPKTINFO, &on) < 0)
                perror("IPV6_RECVPKTINFO");
#else
        if (setsockopt(s, SOL_IPV6, IPV6_PKTINFO, &on) < 0)
                perror("IPV6_RECVPKTINFO");
#endif

        You can substitute any of the options for "PKTINFO"
here (e.g., s/PKTINFO/DSTOPTS/g)
        There is no sticky option support currently, so the
only concern as far as continuing to work after the change
is sendmsg() processing, but that doesn't require any
source change. In both APIs, you use IPV6_x as the cmsg_type
on the sendmsg(). It's just that IPV6_x is a boolean receive
when used as a socket option in the old API, and a sticky
option for data in the new one.
        If your concern is binary compatibility, you can use
something like the patch I posted on netdev@xxxxxxxxxxxxxxx
(archived as linux-netdev on marc.theaimsgroup.com, I believe).
The changes suggested by Yoshifuji allow existing binaries to
continue to work-- they would just have to have source fixes
when they are recompiled (unless they already have #ifdefs as
above).
        I'm sure the final kernel.org patch for this support
will include something like that.
        I don't think a run-time config parameter is needed,
since it's easy to detect which style the app. is using
for binaries, and it isn't a choice-- the new API is the
standard and the old API is obsolete. So, these programs
should be fixed (with either #ifdefs as above, for
portability among old and new systems), or just a plain
edit to add the "RECV" on boolean socket option calls
after the transition.
        Also, these aren't hidden. All cases that were
supported in the old kernel will return an error under
the new API (EINVAL) because the argument won't be the
right size.

[and after typing all this, I see you're saying
"run-time dependent" -- here's how to do that...]

If you're compiling on a system that supports both,
then you can call setsockopt with IPV6_RECVx. If that
returns ENOPROTOOPT (I think that's the errno for an
invalid socket option-- should check), then call again
with "IPV6_2292x" (or whatever the old value is defined
as in the eventual patch).

Alternatively, you can call with "IPV6_x" and a boolean
option and if that returns "EINVAL", then call with
"IPV6_RECVx".

The ancillary data processing is a little trickier, but
it'll either be the old value of IPV6_x or the new one,
so you can treat those as equivalent in recvmsg. If you do a
socket option as above and set a flag to remember which
flavor of kernel you have, you can use the appropriate
one for both sendmsg() and recvmsg(). Without that, for
sendmsg(), you'll get "EINVAL" when using a new cmsg_type
on a kernel that doesn't support it, so then you switch
to the old value (assuming that's the cause of the
EINVAL :-)). In the kernel.org patch, the old
value is, e.g., "IPV6_2292PKTINFO" and the new one is
"IPV6_PKTINFO".

Since none of this is in the kernel.org kernel yet, some
of the details may of course change. :-)

                                                +-DLS