Test version of glibc 2.3.5-10, kfreebsd-amd64
Petr Salinger
Petr.Salinger at t-systems.cz
Mon Jan 2 15:24:12 UTC 2006
On Mon, 2 Jan 2006, Aurelien Jarno wrote:
> Hi
>
> On Mon, Jan 02, 2006 at 12:18:43PM +0100, Petr Salinger wrote:
> > > There is still a few problem to be solved before though:
> >
> > > * struct statfs & syscalls.list upgrade
> > >
> > > Personally I would prefer that the change in the structure is handled
> > > via symbol versioning, therefore we don't need to break the ABI.
> > >
> > > Please also note that when the port will move to ftp.debian.org (aj said
> > > at the end of the month), it will not be possible to break the ABI.
> > >
> > > We can live with the old syscalls, however I think we have to switch to
> > > at least 5.4 soon.
> >
> > I will write necessary wrappers for struct statfs and related syscalls.
> > They will be ABI compatible with glibc 2.3.0 on kfreebsd-i386,
> > symbol versions will be unchanged.
>
> I have already started to work on this. First please find below the list of
> packages that uses those syscalls:
> As you can see there is not a lot of file. I already have here wrappers
> for statfs, statfs64, fstatfs, fstatfs64, fhstatfs and fhstatfs64.
>
> As for getfsstat, getfsstat64, getmntinfo, getmntinfo64, the wrappers
> are not trivial, unless we still uses old syscall. But given the number
> of package affected (5), I think we could break the ABI, and do some binNMU.
> I forget to say that in my implementation statfs == statfs64.
> Any comments?
We don't have to break ABI at all.
Kernel structure don't have to be the same as user structure.
In 2.3.0, user structure statfs is the same as in kernel,
but statfs64 is different -> conversion is needed anyway.
I am now testing approach simillar to stat() interface,
with wrappers like stat32conv.c, stat16conv.
User structure statfs and statfs64 on i386 are the same as in 2.3.0.
The only exceptions are
__undefined1 -> f_version
__undefined2 -> f_namemax
It will retain 100% backward compatibility on i386.
But my machine is not the fastest one,
so just now I have only untested patch for all affected syscalls.
Petr
More information about the Glibc-bsd-devel
mailing list