Message ID | 20190110162435.309262-1-arnd@arndb.de (mailing list archive) |
---|---|
Headers | show |
Series | arch: synchronize syscall tables in preparation for y2038 | expand |
Hi Arnd, On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann <arnd@arndb.de> wrote: > The system call tables have diverged a bit over the years, and a number > of the recent additions never made it into all architectures, for one > reason or another. > > This is an attempt to clean it up as far as we can without breaking > compatibility, doing a number of steps: Thanks a lot! > - Add system calls that have not yet been integrated into all > architectures but that we definitely want there. It looks like you missed wiring up io_pgetevents() on m68k. Is that intentional? Gr{oetje,eeting}s, Geert
On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Arnd, > > On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann <arnd@arndb.de> wrote: > > The system call tables have diverged a bit over the years, and a number > > of the recent additions never made it into all architectures, for one > > reason or another. > > > > This is an attempt to clean it up as far as we can without breaking > > compatibility, doing a number of steps: > > Thanks a lot! > > > - Add system calls that have not yet been integrated into all > > architectures but that we definitely want there. > > It looks like you missed wiring up io_pgetevents() on m68k. > Is that intentional? Yes, I thought I had described that somewhere but maybe I forgot: semtimedop() and io_pgetevents() get replaced with time64 versions in the follow-up, so I only added them in 64-bit architectures. If you think we should have both io_pgetevents() and io_pgetevents_time32() on all 32-bit architectures, I can add that as well. Arnd
On Thu, 10 Jan 2019, Arnd Bergmann wrote: > - Add system calls that have not yet been integrated into all > architectures but that we definitely want there. glibc has a note that alpha lacks statfs64, any plans for that?
Hi Arnd, On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > The system call tables have diverged a bit over the years, and a number > > > of the recent additions never made it into all architectures, for one > > > reason or another. > > > > > > This is an attempt to clean it up as far as we can without breaking > > > compatibility, doing a number of steps: > > > > Thanks a lot! > > > > > - Add system calls that have not yet been integrated into all > > > architectures but that we definitely want there. > > > > It looks like you missed wiring up io_pgetevents() on m68k. > > Is that intentional? > > Yes, I thought I had described that somewhere but maybe I > forgot: semtimedop() and io_pgetevents() get replaced with > time64 versions in the follow-up, so I only added them in > 64-bit architectures. If you think we should have both > io_pgetevents() and io_pgetevents_time32() on all 32-bit > architectures, I can add that as well. Thanks, sounds fine to me. Gr{oetje,eeting}s, Geert
On Thu, Jan 10, 2019 at 7:10 PM Joseph Myers <joseph@codesourcery.com> wrote: > > On Thu, 10 Jan 2019, Arnd Bergmann wrote: > > > - Add system calls that have not yet been integrated into all > > architectures but that we definitely want there. > > glibc has a note that alpha lacks statfs64, any plans for that? Good catch, I missed that because all other 64-bit architectures have a statfs() call with 64-bit fields. I see that it also has an osf_statfs64 structure and system call with lots of padding and some oddly sized fields: f_type, f_flags and f_namemax are only 16 bits wide, the rest is all 64-bit. Adding the regular statfs64() should be easy enough, we just need to decide which layout to use: a) use the currently unused 'struct statfs64' as provided by the alpha uapi headers, which has a 32-bit __statfs_word but 64-bit f_blocks, f_bfree, f_bavail, f_files, and f_ffree. b) copy asm-generic/statfs.h to the alpha asm/statfs.h and change statfs64 to have the regular layout that we use on all other 64-bit architectures, using all 64-bit fields. The other open question for alpha (as mentioned in one of the patches I sent) would be whether to add get{eg,eu,g,p,pp,u}id() with the regular calling conventions. Arnd
On Thu, Jan 10, 2019 at 7:11 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann <arnd@arndb.de> wrote: > > On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > > The system call tables have diverged a bit over the years, and a number > > > > of the recent additions never made it into all architectures, for one > > > > reason or another. > > > > > > > > This is an attempt to clean it up as far as we can without breaking > > > > compatibility, doing a number of steps: > > > > > > Thanks a lot! > > > > > > > - Add system calls that have not yet been integrated into all > > > > architectures but that we definitely want there. > > > > > > It looks like you missed wiring up io_pgetevents() on m68k. > > > Is that intentional? > > > > Yes, I thought I had described that somewhere but maybe I > > forgot: semtimedop() and io_pgetevents() get replaced with > > time64 versions in the follow-up, so I only added them in > > 64-bit architectures. If you think we should have both > > io_pgetevents() and io_pgetevents_time32() on all 32-bit > > architectures, I can add that as well. > > Thanks, sounds fine to me. Just to be sure, you mean it's fine to not add it, not that we should add it? Arnd
On Thu, Jan 10, 2019 at 11:42:32PM +0100, Arnd Bergmann wrote: > On Thu, Jan 10, 2019 at 7:10 PM Joseph Myers <joseph@codesourcery.com> wrote: > > > > On Thu, 10 Jan 2019, Arnd Bergmann wrote: > > > > > - Add system calls that have not yet been integrated into all > > > architectures but that we definitely want there. > > > > glibc has a note that alpha lacks statfs64, any plans for that? > > Good catch, I missed that because all other 64-bit architectures > have a statfs() call with 64-bit fields. I see that it also has an > osf_statfs64 structure and system call with lots of padding and some > oddly sized fields: f_type, f_flags and f_namemax are only 16 bits > wide, the rest is all 64-bit. > > Adding the regular statfs64() should be easy enough, we just need to > decide which layout to use: > > a) use the currently unused 'struct statfs64' as provided by the > alpha uapi headers, which has a 32-bit __statfs_word but > 64-bit f_blocks, f_bfree, f_bavail, f_files, and f_ffree. > > b) copy asm-generic/statfs.h to the alpha asm/statfs.h and > change statfs64 to have the regular layout that we use > on all other 64-bit architectures, using all 64-bit fields. > > The other open question for alpha (as mentioned in one of the > patches I sent) would be whether to add get{eg,eu,g,p,pp,u}id() > with the regular calling conventions. I would be interested in seeing those provided on Alpha. There are a handful of projects choosing to sidestep glibc for these syscalls and they break on Alpha. Such projects are never keen to include special assembler code (because the extant syscalls on Alpha are not C ABI compliant) to support a legacy arch. Cheers Michael.
Hi Arnd, On Thu, Jan 10, 2019 at 11:43 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Thu, Jan 10, 2019 at 7:11 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Thu, Jan 10, 2019 at 6:06 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > On Thu, Jan 10, 2019 at 5:59 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > On Thu, Jan 10, 2019 at 5:26 PM Arnd Bergmann <arnd@arndb.de> wrote: > > > > > The system call tables have diverged a bit over the years, and a number > > > > > of the recent additions never made it into all architectures, for one > > > > > reason or another. > > > > > > > > > > This is an attempt to clean it up as far as we can without breaking > > > > > compatibility, doing a number of steps: > > > > > > > > Thanks a lot! > > > > > > > > > - Add system calls that have not yet been integrated into all > > > > > architectures but that we definitely want there. > > > > > > > > It looks like you missed wiring up io_pgetevents() on m68k. > > > > Is that intentional? > > > > > > Yes, I thought I had described that somewhere but maybe I > > > forgot: semtimedop() and io_pgetevents() get replaced with > > > time64 versions in the follow-up, so I only added them in > > > 64-bit architectures. If you think we should have both > > > io_pgetevents() and io_pgetevents_time32() on all 32-bit > > > architectures, I can add that as well. > > > > Thanks, sounds fine to me. > > Just to be sure, you mean it's fine to not add it, not that we should > add it? I'm fine with not having the legacy 32-bit ones. Sorry for being unclear. Gr{oetje,eeting}s, Geert