Primary goals of uClibc

Rich Felker dalias at aerifal.cx
Tue May 16 05:33:55 UTC 2006


On Tue, May 16, 2006 at 07:19:46AM +0200, Jan-Benedict Glaw wrote:
> On Tue, 2006-05-16 01:13:45 -0400, Rich Felker <dalias at aerifal.cx> wrote:
> > On Tue, May 16, 2006 at 12:26:10AM -0400, Mike Frysinger wrote:
> > 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
> 
> It's not "better."  Using the same ABI (as far as possible, including
> calling conventions, syscall and error numbers) means that there's a
> remote change to run a program pulled from the original operating
> system.

I think you missed what I was saying. Whether the kernel should use
the same ABI as the legacy unix for the particular cpu did is a
question that can be considered on its own, but I was talking about
whether the libc should use the kernel struct or translate it.

Specifically, I see no reason uClibc should waste code size
translating the struct from the kernel format to the glibc format
instead of just declaring the struct in a format compatible with the
kernel one.

For my implementation I do translation, but that's because there's a
real need: my time_t does not match the kernel's time_t.

Rich




More information about the uClibc mailing list