RFC: ABI break

Petr Salinger Petr.Salinger at t-systems.cz
Thu Dec 29 17:54:21 UTC 2005


Hi!

> I don't say we should not change the soname, but we should avoid that if
> possible. If it is not possible, we should do it, but I expect a
> duration of one or two months.

Just now, there is some ABI skew, exposed in libqt3-mt.
But I don't know reason for this ABI change.
There might be more similar problems.

We should collect pros and cons for all approaches, 
test new glibc and decide later, based on results.

> > - kfreebsd-kernel-headers based on FreeBSD 6.0
> 
> What is the benefit of doing that? You show us that there is very few
> differences in the syscalls, but there is probably a lot more
> differences in the .h files, that are used by userspace programs, so I
> expect some breakage there.

Since there are no redefinition of syscalls, structures passed between 
kernel space and user space should be compatible.

Expected differences between headers from 5.4 and 6.0:

- more defined errors in errno.h
- more cmd for ioctl
- unused field in a structure got a meanning
- extra structures for audit, syscall numbers for audit
- ...

Expected etch release is after 12 months,
these days might be kernel of FreeBSD 6.x the preferred one.

> Before we could declare the 5.4 kernel
> obsolete, we should avoid such things.

Even if some structure changes completely,
we can emulate changes inside libc. Just now we 
convert from newer kernel structure into older user structure.
We can do it also in opposite way.

It will be similar as with linux-kernel-headers.
In sarge, they are based on 2.6.0 everywhere,
supported kernels are 2.6.8 and 2.4.27 in general
and on some archs also 2.2.x

Petr





More information about the Glibc-bsd-devel mailing list