In article <20070530031123.GA16216@panix.com>,
Thor Lancelot Simon  <tls@rek.tjls.com> wrote:
>On Tue, May 29, 2007 at 08:06:59PM -0400, der Mouse wrote:
>> > sockaddr_storage is, by definition, large enough to contain any
>> > protocol-specific sockaddr.  That's what it's for.
>> 
>> Then it needs to be enlarged substantially; the only limit on AF_LOCAL
>> sockaddr size I can find is the one implied by the various *_len fields
>> (including sun_len) being unsigned char.  (I consider this limit a bug,
>> especially as it's not documented as far as I can see.  unix(4) implies
>> the limit is 104, without giving a manifest constant for the limit,
>> without explaining why it's 104 and not, say, 126, and without
>> explaining that the actual limit is entirely different.)
>
>Without taking up the other issue (where I mostly agree with you): I don't
>think _this_ use of sockaddr_storage in a structure is a problem with
>regard to AF_LOCAL, because you can't do an interface ioctls on an AF_LOCAL
>socket: it has no interface.
>
>If there are other sockaddrs hiding in structures sent up to or down from
>the kernel, I agree, the size needs to get larger to handle AF_LOCAL
>addresses, the length on the limit of which should, in fact, be documented,
>regardless.
>
>I think a sockaddr_storage is 256 bytes on FreeBSD.  Maybe it should be
>here, too, to address this issue.  But *that* would, I think, present a
>whole new set of backwards compatibility issues.

It is 128 on FreeBSD too. I think that we can make it 256 *right now*
without causing any grief and riding on the ifreq changes. But yes, if
we wait longer we will need to deal with another ifreq versioning. Also
we could just leave sockaddr_storage alone and add another member in
ifru that is let's say 256 or 512. Should we?

christos