On Tue, Feb 14, 2006 at 04:50:13PM -0800, David Stevens wrote:
> [EMAIL PROTECTED] wrote on 02/14/2006 04:23:28 PM:
>
> > In linux/igmp.h:
> >
> > struct ip_mc_list
> > {
> > struct in_device *interface;
> > unsigned long multiaddr;
> > struct ip_sf_list *sources;
> >
> > and AFAICS all users of ->multiaddr assume it's __be32. Are there any
> > good reasons to use unsigned long here? On 32bit boxen it's all the
> same,
> > but on 64bit ones things might get funnier...
>
> Though I'm not the "Dave" you asked, I think I'm the last one to
> touch this structure...below is my answer to add to the real Dave's. :-)
> I think it's historical, and has no need to be "unsigned long".
> Also, the order of these fields shouldn't matter, so if rearranging
> them provides pad, cache or alignment benefits, that should work too.
> Similarly, the historical "char" flags and counters and "int
> users"
> could/should be "unsigned char" and "unsigned" respectively, as the
> newer source filtering fields already are, if you want to do that too. :-)
The only real concern here is if there's a _very_ hot path where some
64bit targets would win from unsigned long. I don't see any, but...
A bit of context: I'm doing a _long_ series of endianness annotations in
net/*; this was one the places that did show up.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
