Primary goals of uClibc

[Mike Frysinger]

On Monday 15 May 2006 22:55, Rich Felker wrote:
> On Mon, May 15, 2006 at 10:29:28PM -0400, Mike Frysinger wrote:
> > On Monday 15 May 2006 16:08, Rich Felker wrote:
> > > Last I checked uclibc _does_ use the same struct provided by the
> > > kernel, but then 'converts' it anyway.. :)
> >
> > no, uclibc does the samething glibc does
> >
> > each arch defines the stat structure as the kernel sees it and then
> > converts it to the same stat structure for everyone regardless of
> > architecture
> >
> > thus the only people who care about the kernel craziness is the libc ...
> > userland programs use stat() as defined by the libc and everything is
> > peachy
>
> what i said is correct. look at:
>
> libc/sysdeps/linux/common/bits/stat.h
> libc/sysdeps/linux/i386/bits/kernel_stat.h

but not all arches are like this as i said ... the libc hides the differences

> 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.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20060516/a8ef8c82/attachment-0002.pgp