Primary goals of uClibc

Rich Felker dalias at aerifal.cx
Tue May 16 05:13:45 UTC 2006


On Tue, May 16, 2006 at 12:26:10AM -0400, Mike Frysinger wrote:
> > the stat64 and kernel_stat64 structs are identical in the binary
> > image. yes there is legacy non-largefile-supporting stat mess too, but
> > there's absolutely no reason to support that. it's just extra bloat in
> > uclibc. it could be removed and then the xstatconv code could be
> > removed too.
> 
> currently uClibc offers the ability to use all non-lfs or the normal 
> non-lfs/lfs combo.  at this point, prob the only patch acceptable would be to 
> have a config option to enable a lfs-only system.

The names used are utterly misleading. Using stat64 has nothing to do
with lfs or with whether you'll be opening files in 64bit mode; it's
just a more modern version of the stat syscall. Regardless of whether
large files are enabled or not, stat64 syscall should always be used
and the legacy stat syscalls should never be used.

However you are correct that on non-i386 archs the glibc structure
does not match the kernel structure. I assume this is due to the
original (pre-personality) decision by Linus to use existing
proprietary unix ABI's. However I don't really see how the glibc stat
struct is any better than the native ones in this case. Both have the
same limitations; it's just a matter of reordering the struct. And I
don't see how userspace apps should care what order the struct is in
as long as it stays fixed between libc versions...

Rich






More information about the uClibc mailing list