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] |
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] |