Hi Jesse,
> Your subject should indicate net or net-next as the tree, please see:
I was intending more to see if this is an intrinsically bad idea than for it to
go directly into a tree right now.
> Not sure how many patches you've submitted, but your commit message
> should be wrapped at 68 or 72 characters or so.
Not my first patch, but the first sent through Thunderbird and Outlook.
> your triple-dash and a diffstat should be right here, did you hand edit
> this mail instead of using git format-patch to generate it?
Yup, the log message on my internal commit wouldn't make too much sense outside
of Akamai, so I wrote this changelog in my MUA.
> Why is this added in the middle of the includes?
I needed to get IN_MULTICAST defined - this is one reason I don't expect this
patch as it stands to go anywhere. IN_MULTICAST seems intended just for
userspace use, but there isn't any way to ask the same question in the kernel.
The same seems to be true of IPv6 multicast addresses.
>> +static int arp_is_multicast(const void *pkey)
>> +{
>> + return IN_MULTICAST(htonl(*((u32 *) pkey)));
>> +}
>
> Why not just move this function up and skip the declaration above?
Following existing practice in this file. Similar functions are declared above
the structure and defined below it.
>>
>> +static int ndisc_is_multicast(const void *pkey)
>> +{
>> + return (((struct in6_addr *) pkey)->in6_u.u6_addr8[0] & 0xf0) == 0xf0;
>> +}
>> +
>
> Again, just move this up above the first usage?
Following existing practice again.
>
> Does the above work on big and little endian, just seems suspicious
> even though you're using a byte offset? Also I suspect this will
> trigger a warning with sparse or with W=2 about pointer alignment.
I used the byte offsets on purpose for this reason. Didn't check if sparse had
any problems with it.
Jeff
