This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [COMMITTED PATCH] Move tilegx, tilepro, and linux-generic from ports to libc.


On 03/19/2015 12:44 PM, H.J. Lu wrote:
On Thu, Mar 19, 2015 at 9:31 AM, Chris Metcalf <cmetcalf@ezchip.com> wrote:
On 03/18/2015 07:59 AM, H.J. Lu wrote:
Any particular reason to add sysdeps/unix/sysv/linux/generic/bits/statfs.h
when there is sysdeps/unix/sysv/linux/bits/statfs.h already? Why can't it be
used?

The distinction lies with the the fields defined by __field64 in the
"generic" version.  For the case without __USE_FILE_OFFSET64, but when ILP32
mode is involved, the base linux version uses plain __fsblkcnt_t, i.e.
unsigned long, so just 32 bits.  However, it needs to be a 64-bit field,
where either the first or second 32-bit subfield is padding depending on
endianness, and the field value is the other 32-bit subfield.  We would need
to adopt the __field64 scheme for the base version in some way that allowed
platforms to turn it on as needed (depending on whether statfs is filled
with a statfs64 syscall or a plain 32-bit statfs syscall on older, non
asm-generic 32-bit kernels).  This is doable but fiddly to get exactly
right.

Another difference I see is easy to work around.  The "generic" linux
version uses __SWORD_TYPE where the base version uses __fsword_t (changed by
hjl in 2012).  If the generic platforms (tile, aarch64, nios2) switched,
this would be OK since the types are the same on those platforms.  (Only
alpha and x32 define them differently.)
There are

sysdeps/unix/sysv/linux/mips/bits/statfs.h
sysdeps/unix/sysv/linux/alpha/bits/statfs.h
sysdeps/unix/sysv/linux/bits/statfs.h
sysdeps/unix/sysv/linux/s390/bits/statfs.h

If sysdeps/unix/sysv/linux/bits/statfs.h can't be used for
a Linux platform, it should define its own statfs.h, like
alpha, mips and s390.

The linux/generic layer is essentially an intermediate layer for all new Linux ports that use the asm-generic syscall interface. Rather than "inheriting" directly from the sysdeps/unix/sysv/linux/, newer ports inherit from sysdeps/unix/sysv/linux/generic/, which tweaks whatever needs tweaking to support the fact that a far smaller set of syscalls is available on such platforms. This means tile, aarch64, and nios2 don't have to each provide their own replacement statfs.h.

Having both

sysdeps/unix/sysv/linux/generic/bits/statfs.h

and

sysdeps/unix/sysv/linux/bits/statfs.h

is very strange.

Yes, I don't love the naming either, but no one could come up with anything better when this was initially introduced.

It may be the case that we can do some unification along the lines I suggested in my previous email, but the tricky part is figuring out programmatically which platforms are using the new API (and thus don't have a version of statfs with 32-bit fsword_t) and which are using the old API. Or, moving forward, which platforms are using the LP64 version of the syscall even in ILP32 mode (x32, aarch64:ILP32). Since this is a public header we don't have kernel-features.h. I'm not sure where else we would normally place this kind of information in the headers.

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]