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 Thu, Mar 19, 2015 at 9:59 AM, Chris Metcalf <cmetcalf@ezchip.com> 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.
>
>> 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.
>

How about sysdeps/unix/sysv/linux/asm-generic/bits/statfs.h?


-- 
H.J.


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