On 3/29/2015 11:26 AM, Thor Lancelot Simon wrote:
On Sun, Mar 29, 2015 at 11:18:48AM -0400, Tyler Retzlaff wrote:After thinking about it for a couple of days I don't see how changing the size of sockaddr_storage has any benefit. As you point out doing so would require even more change for ABI compatibility. The only gain appears to be avoiding definition of a new structure that would be used only in the kernel. Maybe there's more?I don't agree. Ask yourself what sockaddr_storage is _for_ if it's not meant to be able to contain an arbitrary address for an arbitrary protocol. It confounds expectations that we have a protocol whose addresses won't fit.
I completely agree. But it is the way it is.
Creating another structure with the same purpose but a different name, and papering over that that's what's been done by hiding the new one from userspace, is not the right answer. Or so it seems to me.
When literally interpreted sockaddr_storage shall be large enough to contain any sockaddr_foo and it does. What would trigger a size change is if one of those sockaddr_foo's was increased in size.
So would you advocate increasing the size of sockaddr_un also then? Because if the right answer is to grow sockaddr_storage then it seems the same logic applies.
In fairness I should note that at a former employer I wrote a great deal of code that passes sockaddr_storage structures around in userspace. So there are application maintainers, like them, who would experience a flag day. But I still think we should do the right thing rather than make a mess.
The mess was already made when we started permitting non-sockaddr_foo structures to be shoved into an interface taking sockaddr *.
I'm not wedded to the patch, but if you're just going to call it "a mess" I think I deserve a little bit more qualification. I accept that there may be valid reasons for using either the same or different structures but I think it's important to document them here.
rtr