2010/11/16 Stuart Henderson <s...@spacehopper.org>:
> On 2010/11/16 04:50, Vadim Zhukov wrote:
> [..]
>
> Great stuff, this has annoyed me for a while :) I can't test today but
> will try and do that soon. I won't be able to really test pfsync though..
>
>> B - More style(9) compliance. Not sure about struct pf_state change,
>> B B though: will it ever break on architectures with 4-byte pointers
>> B B but 64-bit alignment requirements, if there are any?.. Sorry for
>> B B possibly stupid question.
>
> Afaik the strictest requirements on any arch we support is that
> a data type must be aligned to the size of that data type. 32-bit
> aligned for 4-byte types, 64-bit aligned for 8-byte types, etc.
>
>> @@ -807,6 +808,7 @@ struct pf_state {
>> B B B struct pf_state_key B B *key[2]; B B B B /* addresses stack
and wire B */
>> B B B struct pfi_kif B B B B B *kif;
>> B B B struct pfi_kif B B B B B *rt_kif;
>> + B B struct pf_rule B B B B B *rt_rule;
>> B B B u_int64_t B B B B B B B B packets[2];
>> B B B u_int64_t B B B B B B B B bytes[2];
>> B B B u_int32_t B B B B B B B B creation;
>
> I might be mistaken but I think this will break compatibility with
> the pfsync wire format used by earlier versions.
No, it's struct pfsync_state that shows on the wire. You don't think
that pointers being used in pfsync messages, do you? :)
--
WBR,
Vadim Zhukov
