[uClibc] fstat and fstat64

[John Bowler]

From: Mike Frysinger [mailto:vapier at gentoo.org]
>it looks like the current stat.h is based on linux-2.4's stat64 definition
...
>2.6 has a much different (and better) stat.h, so how does the attached
patch
>look ?  (i havent tried compiling with it)

It looks to me like unnecessary complexity.  kernel_stat (in uClibc) works
fine as it is, and the 2.6 version is goofy at best.  The bug is in
kernel_stat64.  The 2.6 header (i.e. the one in the 2.6 kernel sources)
matches the layout in a 2.4 kernel, so why not just use it?  What's more the
patch doesn't actually seem to fix the bug which my patch fixed (st_dev and
st_rdev are still both wrong on a big-endian 2.6 kernel system).

Take a look at that st_dev field.  2.4 had:

 #if defined(__ARMEB__)
 unsigned char __pad0b[6];
 unsigned short st_dev;
 #else
 unsigned short st_dev;
 unsigned char __pad0b[6];
 #endif
 unsigned char __pad0[4];

2.6 has no #if:

 unsigned long long st_dev;
 unsigned char __pad0[4];

While the uClibC copy of (effectively) asm/stat.h
(libc/sysdeps/linux/arm/bits/kernel_stat.h) has (at present):

 unsigned short st_dev;
 unsigned char __pad0[10];

I don't see how this latter can be derived from either the 2.4 header or the
2.6 header ;-).  The 2.6 version is entirely compatible with 2.4 and vice
versa, so why not just use one or the other kernel header definition?

I wrote the patch the way I did because I have no way of testing *little*
endian ARM - what I did is tested on big-endian and doesn't change
little-endian, but the ARMEB branch of the st_dev and st_rdev should work
fine on little-endian (st_block has the #if in the kernel version too).

Now this assumes that the 2.4 kernel really is setting __pad0b and __pad3b
to 0, if it isn't or if it can't be assumed to do so then either uClibc has
to treat the 'dev' fields as unsigned short or it has to use the right
struct for the OS version.  The *first* 'solution' is equivalent to using
the 2.4 kernel header (which would fix my bug just as well because I happen
to know that the dev entries are not more than 16 bits on an NSLU2 ;-)

John Bowler