Re: patch: sockaddr instead of mbuf to carry addresses

[Tyler Retzlaff <rtr%netbsd.org@localhost>]

hey,

On 3/25/2015 7:46 AM, Joerg Sonnenberger wrote:
> On Tue, Mar 24, 2015 at 11:47:56PM +0000, Christos Zoulas wrote:

> Why do we limit sockaddr_un to less than PATH_MAX? There really aren't
> many reasons for it to be shorter. But if we do go that way, using
> sockaddr_storage becomes even less attractive.

The limit of 253 originates from the capacity of sockkaddr_un.sun_len 
being uint8_t.  i.e. the maximum size of the data and members of any 
sockaddr structure when its bounds are described by the len member.

> IMO sockaddr_storage
> should be the union of all network facing addresses and the potentially
> largest is gone with the netiso removal.

I initially made a similar argument (off list) that sockaddr_un 
could/should grow in size to encompass what it was already being used 
for and sockaddr_storage would then have to be grown too by implication 
(ABI difficulties aside).

I accepted a counter argument that if you passed data bigger than a 
sockaddr_un structure with family of AF_UNIX then really your not 
passing a sockaddr structure anymore. If you make that leap then 
sockaddr_storage as defined now is capable of holding any address family 
sockaddr structure as required by susv2.

It gets interpreted as "it holds any of those defined sockaddr 
structures but this data isn't one" (which conveniently ignores the type 
of the parameter sockaddr *).

As for my patch in the kernel it seemed to make sense 
(consistency/simplicity) to use one structure for all even if from 
user-space it was a little less clear.

> Joerg