On Wednesday 2008-11-12 11:32, Adam Nielsen wrote:
>>
>> You now have an alignment problem, and need at least
>> void *internal_data __attribute__((aligned(8)))
>> as explained in the PDF. Ultimatively, these shouls be reordered to
>> accomodate for gaps (see doc).
>>
>> Also, why is it 26?
>
> Ah bummer, I forgot about that. Is this the best order?
No, that will break offsetof() in .userspacesize, as it will
become 0.
> If I'm
> understanding correctly this order shouldn't need member alignment.
>
> struct xt_led_info {
> void *internal_data;
> __u32 delay;
> __u8 always_blink;
> char id[26];
> };
>
> The id[26] is for a 16 char ID + the 10 digit "netfilter-" prefix.
> Actually that's a good point, it needs to be 27 to accomodate the
> terminating NULL. At any rate, I'm not sure of the best way to describe
> that, without using #define. What do you suggest?
struct xt_led_tginfo {
char id[27];
__u8 always_blink;
__u32 delay;
void *internal_data __attribute__((aligned(8)));
};
add id - 27 bytes.
add always_blink - 28 bytes.
28? That's good for alignment of a u32. Add delay.
32? That's good for alignment of a potentially-ptr64.
And it's solved, even without thinking of NULs or prefixes.
>
> /* strlen("netfilter-") + 16 char user-definable name */
> #define LED_TRIGGER_ID_LENGTH (10 + 16)
>
> char id[LED_TRIGGER_ID_LENGTH + 1];
>
> In that case it might be worth #defining the 16 char part separately,
> so that it can be used in the parameter verification code too. Let
> me know what you think.
Just use [27] - the struct will be hardcoded forever,
and putting #defines somewhere gives a wrong illusion it might be changeable.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
