Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1366587
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 |
| Date | 2016-03-29 21:40 +0200 |
| Message-ID | <ri7EB-2oO-7@gated-at.bofh.it> (permalink) |
| References | <qQTSG-1KH-7@gated-at.bofh.it> <ri1SA-6PD-17@gated-at.bofh.it> <ri4dJ-8rn-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tuesday 29 March 2016 15:54:52 Joseph Myers wrote: > On Tue, 29 Mar 2016, Arnd Bergmann wrote: > > > In glibc, I think we need to define fewer entry points, not more. > > Instead of having both lseek and lseek64, only one of them should > > be provided, and that should always take a 64-bit offset, calling > > into the kernel with the _llseek syscall entry. > > lseek64 is part of the public API, on all platforms. It should be aliased > to lseek where possible. Right, makes sense. > Strictly, it would be possible to provide it in the API without it being > part of the ABI, by arranging the headers so that calls to lseek64 result > in objects with a reference to lseek (because it uses the off64_t typedef, > it's not valid to declare it yourself rather than including a header that > declares it). I don't think it would be a good idea for a new > sub-architecture port to try introducing such a difference from all other > ports, however. How do we do it then? Should we just define __USE_FILE_OFFSET64 unconditionally for all new 32-bit architectures and leave the code dealing with 32-bit off_t/ino_t in place but unreachable, to minimize the differences? Or should all the obsolete types be defined the same way as their replacements so we have 64-bit __OFF_T_TYPE/__INO_T_TYPE and use the same binary implementation regardless of FILE_OFFSET_BITS? Arnd
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2016-03-18 11:40 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Alexander Graf <agraf@suse.de> - 2016-03-18 17:00 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2016-03-20 09:20 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2016-03-21 12:30 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Yury Norov <ynorov@caviumnetworks.com> - 2016-03-21 20:20 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2016-03-21 10:10 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-03-21 10:50 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Andreas Schwab <schwab@suse.de> - 2016-03-21 12:00 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-03-21 18:10 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2016-03-26 13:40 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-03-29 13:00 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-03-29 14:50 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2016-03-29 15:30 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-03-29 15:30 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Joseph Myers <joseph@codesourcery.com> - 2016-03-29 18:00 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-03-29 21:40 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Joseph Myers <joseph@codesourcery.com> - 2016-03-29 22:20 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-03-29 22:30 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Joseph Myers <joseph@codesourcery.com> - 2016-03-29 23:10 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Arnd Bergmann <arnd@arndb.de> - 2016-03-29 23:50 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2016-03-31 09:40 +0200
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2016-03-26 14:20 +0100
Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 "Zhangjian (Bamvor)" <bamvor.zhangjian@huawei.com> - 2016-03-26 14:50 +0100
csiph-web