[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 26 Apr 2008 00:13:34 -0700
From: David Stevens <dlstevens@...ibm.com>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, netdev-owner@...r.kernel.org,
yoshfuji@...ux-ipv6.org
Subject: Re: [GIT PULL] [IPV6] COMPAT: Fix SSM applications on 64bit kernels.
> If you're going to use callbacks, and I'd be also asking you to
> guard this code with CONFIG_IPV6 as appropriate, why not simply
> put it into the ipv6 socket option handling code?
Well, I didn't want to make 2 copies of completely identical
code and then just change the protocol setsockopt code we call at
the end of it. If we did this:
compat_ipv6_setsockopt()
{
if (got an MCAST* optval)
return compat_mc_setsockopt(....optval, optlen,
ipv6_setsockopt);
}
and in compat_mc_setsockopt:
int compat_mc_setsockopt(...., func decl) {
...all common code that twiddles args for both IPv6 and IPv4
return func(....);
}
Then there are no cross references to anything else in the
compat code and we can't get there with func==ipv6_setsockopt unless
we were called from compat_ipv6_setsockopt(), which means we must have
ipv6_setsockopt(). Right? The protocol setsockopt functions are already
external, so I'd expect compat would need any CONFIG guarding. Am I
missing something?
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists