Subject: Re: sizeof(sockaddr_in6) % 8 != 0 (more on 2553)

From: Mukesh Kacker <[email-masked]>
Date: Sun, 20 Feb 2000 17:39:36 -0800 (PST)

>To: [email-masked]
>X-Template-Reply-To: [email-masked]
>X-Template-Return-Receipt-To: [email-masked]
>X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD  90 5F B4 60 79 54 16 E2
>Subject: Re: sizeof(sockaddr_in6) % 8 != 0 (more on 2553)
>From: [email-masked]
>Date: Mon, 21 Feb 2000 09:32:39 +0900
>
>   I just would like to know how people solved this for
>	other 64bit-ready operating systems with SIOCGIFCONF, and tried to
>	list possible solutions.
>

Itojun,
	I have not clearly understood the constraints you are working
with (on alpha ?) but I can offer some general trivia based on experiences
with Solaris code which supports many different ABIs (and I will not bore
you/list with details of those) but they do affect the design of data
structures.

Firstly the assertion you use in the subject line

	sizeof(sockaddr_in6) % 8 != 0

is not really what determines/constraints its alignment, it is the
constraint imposed by the "largest alignment" member in it.

Thus it is conceivable that even if you increase it to be a multiple of
8, and it still starts with a 4 byte aligned (but not 8 byte aligned
boundary) on some architectures so I will advise being careful.

Another factor is that the boundary used by the star of the kernel buffers
when ioctl data is copied from user to kernel land.
The design of data structures is affected by the ABI constraints and anything
that embeds such a data structure also has to be careful with padding etc.

For example, Solaris 64-bit kernel runs both ILP32 and LP64 user
level applications (effectively supporting two ABIs) and therefore has
to be careful that after data copies from either userland
buffers, into the LP64 kernel it will see them the same way. That may
or may not be a factor in your environment. Having that binary compatibility
was a constraint for us.

Those were general principles,  I can roughly tell you what we do in the
those specific instances, but I am not sure how much of that will apply
to your case (and I do not want another religious battle about the one
true design of SIOCG* data structures :-) just reporting what we have).

We do define a new ioctl API (SIOCGLIFCONF - extra L in ioctl name) which
has larger sockaddr's.

Also, to take care of alignment and storage constraints we use the
new sockaddr_storage data structure which, on architectures where it
is supported, gets 8 byte aligned. The technique to force that alignment
is specific to our implementation and uses hidden fields etc to achieve that.

Some of the SIOCG* ioctl data structures that embed sockaddr_storage
are carefully designed so that it falls on 64-bit boundary even if it is
on architectures where the ABI does not guarantee it (e.g. Intel IA32
ILP32 architecture) so that when they get copied into a LP64 kernel,
they get processed an an indentical manner for ILP32 and LP64 environments.

I can send you (or anyone else) the headers which can be perused
to understand atleast the experience of one vendor and will not
pollute the list with it. (Our headers support Sparc and Intel
32 and 64 bit ABIs and are atleast portable enough for those).
If you have specific questions on alignment feel free to ask offline
and I will keep it away from the list as often these issues take
up way too many interations to get across :-)

-Mukesh Kacker
Solaris Internet Engineering
[email-masked]

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Mon, 21 Feb 2000 10:53:59 +0900

>up way too many interations to get across :-)

	Thanks for your reply, I'll email you privately on this.
	I may need to describe gory details...

itojun