In article <20070530031123.GA16216 panix.com>,
Thor Lancelot Simon <tlsrek.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
|
