Test version of glibc 2.3.5-10, kfreebsd-amd64

[Aurelien Jarno]

Petr Salinger a écrit :
>  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.

Yes, it's exactly what I have done for statfs, fhstatfs and fstatfs, 
however, have a look at getfsstat64.c. You will see that the conversion 
is not so tricky, it uses the fact that sizeof(statfs64) > 
sizeof(statfs). This is not the case in our case, so it is not that easy 
to do the conversion. It would be possible using malloc, but I think it 
is a bit dangerous to do that here.

-- 
   .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
  : :' :  Debian developer           | Electrical Engineer
  `. `'   aurel32 at debian.org         | aurelien at aurel32.net
    `-    people.debian.org/~aurel32 | www.aurel32.net