This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [COMMITTED PATCH] Move tilegx, tilepro, and linux-generic from ports to libc.
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Chris Metcalf <cmetcalf at ezchip dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Chris Metcalf <cmetcalf at tilera dot com>, GNU C Library <libc-alpha at sourceware dot org>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>
- Date: Thu, 19 Mar 2015 17:20:09 +0000
- Subject: Re: [COMMITTED PATCH] Move tilegx, tilepro, and linux-generic from ports to libc.
- Authentication-results: sourceware.org; auth=none
- References: <201402101603 dot s1AG30C9000514 at gx-1 dot internal dot tilera dot com> <CAMe9rOpqM3QsZpFnCb57gcWMwFR6acdVCvofV=U40avD78nG8w at mail dot gmail dot com> <550AF9F1 dot 2080600 at ezchip dot com> <CAMe9rOpR29gEFuhGLPg_o1DK0+XHrvFw8zk=zYA5s1QuJ_yAVQ at mail dot gmail dot com> <550B006B dot 5030300 at ezchip dot com>
On 19/03/15 16:59, Chris Metcalf wrote:
> 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.
>
i think aarch64 does not want 32bit blkcnt, that breaks on
a large fs (not even with ilp32)
i'm surprised it is in use on newer 32bit archs at all
(if it is then i think linux asm-generic needs a fix)
>> 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.
>