Subject: Re: ancillary data alignment and binary backward compatibility
To: Chris G. Demetriou <firstname.lastname@example.org>
From: Jun-ichiro itojun Hagino <email@example.com>
Date: 03/09/2000 08:42:46
>Obviously, they're talking about a general 'ALIGN' macro, which may or
>may not be the same as our specific alignment function. our specific
>Note that it says "next even multiple of whatever alignment is
>This is different than the alignment provided by our ALIGN macro and
>ALIGNBYTES value. They align to the maximum possible necessary
>alignment, not the actual alignment needed.
>I'm aware of the old control msg needs for alignment: 4 bytes. (they
>were all 4-byte ints, which in our worst case need to be 4-byte
>As far as I can tell, none of the structures in RFC 2292 will have
>alignment needs > 4 bytes (since at most, they seem to use 4-byte
>fields), unless they're being used on architectures which happen to
>require 8 byte structure alignment (of which there are none that i'm
>aware; some normal ABIs for archs we support require 4-byte alignment
>for structs -- e.g. arm, which we've broken -- but none require 8 that
>i'm aware of).
>I may be missing something here, but ...
>For new ports, going forward, using 'ALIGNBYTES' might be a good thing
>to do, but at this point, i'm not sure why changing the existing
>definition from 3 -> ALIGNBYTES is necessary at all!
I saw couple of align faults on netbsd/alpha, I may need to
double-check if it was from cmsg, or from SIOCGIFCONF.
I'll back out the changes I made soon, until the issue gets resolved.
(hope this to be solved before 1.5 branching...)