[Development] Linux release binaries too old

Thiago Macieira thiago.macieira at intel.com
Tue Aug 26 18:56:51 CEST 2014


On Tuesday 26 August 2014 08:45:38 Blasche Alexander wrote:
> > month in parentheses):
> > 	Arch (rolling release)
> > 	CentOS 7.0 (7/2014)
> > 	Debian testing (no release!)
> > 	Fedora 17 (5/2012)
> > 	Mageia 3 (5/2013)
> > 	Mint 13 (5/2012)
> > 	OpenSUSE 12.2 (9/2012)
> > 	Ubuntu 12.04 (4/2012)
> 
> Ok, I agree that we cannot leave stable Debian behind.
> 
> However I'd like to clarify how and where we formalize which of the distros
> above we care about and/or what condition must be fulfilled when doing an
> upgrade. Not every case is as clear cut as the Debian one.  There is no
> formalization or reference page that I can find. Our docs only talk about
> 11.10, 12.04 and occasional 11.04 tests.

Those are the top 10 distros from distrowatch.com, with a small manual editing 
for relevance.

> > In other words, by upgrading our Ubuntu 11.10 build, we'll drop support
> > for
> > any released Debian. I don't think we can do it.
> 
> This leaves me with only one option. We have to deploy Bluez 4.101 headers
> to 11.10 machines.  It doesn't even have to be a full backport as the
> dependency is a compile time dependency.  My tests have shown that calling
> ::connect() with an extended sockaddr_l2 struct doesn't seem to cause any
> trouble on those older distros.
> 
> Can we agree on that?

Yes.

connect(2) must work with a shorter address. The kernel is very careful about 
keeping compatibility with userspace and they never break it (intentionally). 
Linus's most famous rants are when that happened despite a kernel maintainer 
reviewing (the latest one was Linus calling Mauro a name in Finnish).

As for connect(2) itself, it's no problem since the length of the socket 
address is passed as an extra parameter. Therefore, it's easy for the kernel 
to know whether you meant the old or the new structure. The same size change 
happened for sockaddr_in6 back in 1999/2000: it increased from 24 to 28 bytes 
to add support for the sin6_scope_id field.

Also note you can copy the new structure definition to our source code and use 
that. We *still* do that for IPv6, even 15 years after the sin6_scope_id field 
was added (see struct qt_sockaddr_in6 in 
src/network/socket/qnativesocketengine_p.h). And yes, the kernel still checks 
for the size of sockaddr_in6:

http://lxr.free-electrons.com/source/net/ipv6/af_inet6.c#L320
http://lxr.free-electrons.com/source/net/ipv6/tcp_ipv6.c#L174

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list