[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