Re: [PATCH 00/28] nios2 Linux kernel port
On 14/4/25 下午4:37, Pinski, Andrew wrote: > > >> On Apr 24, 2014, at 11:06 PM, "Chung-Lin Tang" >> wrote: >> >>> On 2014/4/25 02:42 AM, Pinski, Andrew wrote: >>> >>> > On Apr 24, 2014, at 11:37 AM, "Chung-Lin Tang" > wrote: > >> On 2014/4/24 11:28 PM, Catalin Marinas wrote: >>> On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: >> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" >> wrote: >> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. >> >> I believe that arm64 ILP32 will also be affected. What is the status >> of >> this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. >>> >>> Hmm, but that means for purely 32-bit architectures like nios2, which >>> unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit >>> type in the kernel is simply wasted. >> >> The more I think of this, the more I feel that suseconds_t should jsut >> be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit >> kernel should be using compat_* code paths, something like a >> COMPAT_USE_32BIT_SUSECONDS case. > > ILP32 mode should use LP64 syscalls as much as possible and that's the > aim with arm64 as well (of course, we still have a few that wouldn't be > possible and we route them via compat). > > But here if time_t is 64-bit while susecconds_t is 32-bit, the compat > code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32<-->64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. >>> >>> We would three timeval then. One for aarch32, one for lp64 and one for >>> ilp32. We really don't want three. Two is already one too many in my mind >>> after developing the ilp32 syscall abi. >>> >>> Thanks, >>> Andrew >> >> Okay I now see you're already doing that for 32-bit ARM. >> >> Still, you would probably just need to have an arm64-ILP32 specific case >> to be careful about the last padding word upon kernel entry/exit. >> (accommodating the difference in sizeof(long)) Penalizing all >> architectures does not seem like the best solution. > > Considering the alignment of long long would be 64bits, the struct does not > change sizes if suseconds_t is 32bits or 64bits. > >> >> Having suseconds_t as a strictly 64-bit C type in the kernel, while >> defined as <= long in user-space may cause other problems. >> >> I'll try to explain a probable situation for Nios II. I'm not sure about >> other soft-cores, but nios2 is sort of uncommon in that the maximum >> alignment is 4-bytes (32-bits), even for doubles/long-longs. > > Yes does that include even if users of aligned? If so that seems broken. > Also yes nios ii is unstandard when it comes to alignment here. You mean using '__attribute__((aligned(8)))'? Sure of course that enlarges the alignment as expected, but sprinkling that over glibc, or getting it into the main glibc bits/time.h header is probably not going to happen... Thanks, Chung-Lin >> >> So if time_t is 64-bits (which makes sense), then struct timeval, which >> is time_t+suseconds_t in userspace is 12-bytes/aligned-4 (unlike many >> archs where a 64-bit time_t will expand the size to 16-bytes, due to >> align-8) > > Unlike most other targets where the struct would 16bits no matter what. > > Thanks, > Andrew > > >> >> If the kernel suseconds_t is forced to be 64-bits, then nios2 will have >> a 16-byte
Re: [PATCH 00/28] nios2 Linux kernel port
On Fri, Apr 25, 2014 at 8:06 AM, Chung-Lin Tang wrote:
> I'll try to explain a probable situation for Nios II. I'm not sure about
> other soft-cores, but nios2 is sort of uncommon in that the maximum
> alignment is 4-bytes (32-bits), even for doubles/long-longs.
FWIW, that's the same as on m32r. And on m68k it's 2 bytes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
> On Apr 24, 2014, at 11:06 PM, "Chung-Lin Tang" > wrote: > >> On 2014/4/25 02:42 AM, Pinski, Andrew wrote: >> >> On Apr 24, 2014, at 11:37 AM, "Chung-Lin Tang" wrote: > On 2014/4/24 11:28 PM, Catalin Marinas wrote: >> On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: >>> On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: >>> On 2014/4/24 上午 02:15, Pinski, Andrew wrote: >>> > On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" > wrote: > >>> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >>> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann >>> wrote: >>> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>> Hi Arnd and Peter Anvin, >>> >>> Other than 64-bit time_t, clock_t and suseconds_t, can you >>> confirm >>> that we don't need to have 64 bit off_t? See detail in link >>> below. >>> I can submit the patches for 64-bit time changes >>> (include/asm-generic/posix_types.h and other archs) if >>> everyone is >>> agreed on this. >>> >>> Yes. >>> Okay, will doing that. > > I believe that arm64 ILP32 will also be affected. What is the status > of > this configuration? Has the glibc/kernel ABI been finalized? >>> Not yet. I am still working out the signal handling part. But we >>> already agreed on 64bit time_t, clock_t, and suseconds_t. And we >>> agreed to a 64bit offset_t too. >>> >>> On a related note suseconds in the timespec in posix is defined to >>> be long. So it would nice if the kernel ignores the upper 32bits so >>> we (glibc developers) can fix this for new targets including x32 >>> and arm64/ilp32. >> >> Hmm, but that means for purely 32-bit architectures like nios2, which >> unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit >> type in the kernel is simply wasted. > > The more I think of this, the more I feel that suseconds_t should jsut > be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit > kernel should be using compat_* code paths, something like a > COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. >>> >>> Why not? You can define the arm64 'struct compat_timeval' with >>> suseconds_t as s32, and add the 32<-->64 case in the >>> compat_get/put_timeval path, triggered when the process is ILP32 (test >>> wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). >>> Similar to how x32 does COMPAT_USE_64BIT_TIME. >> >> We would three timeval then. One for aarch32, one for lp64 and one for >> ilp32. We really don't want three. Two is already one too many in my mind >> after developing the ilp32 syscall abi. >> >> Thanks, >> Andrew > > Okay I now see you're already doing that for 32-bit ARM. > > Still, you would probably just need to have an arm64-ILP32 specific case > to be careful about the last padding word upon kernel entry/exit. > (accommodating the difference in sizeof(long)) Penalizing all > architectures does not seem like the best solution. Considering the alignment of long long would be 64bits, the struct does not change sizes if suseconds_t is 32bits or 64bits. > > Having suseconds_t as a strictly 64-bit C type in the kernel, while > defined as <= long in user-space may cause other problems. > > I'll try to explain a probable situation for Nios II. I'm not sure about > other soft-cores, but nios2 is sort of uncommon in that the maximum > alignment is 4-bytes (32-bits), even for doubles/long-longs. Yes does that include even if users of aligned? If so that seems broken. Also yes nios ii is unstandard when it comes to alignment here. > > So if time_t is 64-bits (which makes sense), then struct timeval, which > is time_t+suseconds_t in userspace is 12-bytes/aligned-4 (unlike many > archs where a 64-bit time_t will expand the size to 16-bytes, due to > align-8) Unlike most other targets where the struct would 16bits no matter what. Thanks, Andrew > > If the kernel suseconds_t is forced to be 64-bits, then nios2 will have > a 16-byte kernel timeval vs. 12-byte userspace timeval situation. Just > this will require us to do something using compat_*, or weird hacks in > glibc, which is unfair. Nios II has no "other-mode". We are just > strictly ILP32, everywhere. > > Of course, we can probably still at the end just use a Nios II specific > posix_types.h header to override things, but I'm just stating this as a > matter of
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/25 02:42 AM, Pinski, Andrew wrote: > > >> On Apr 24, 2014, at 11:37 AM, "Chung-Lin Tang" >> wrote: >> >>> On 2014/4/24 11:28 PM, Catalin Marinas wrote: On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: > On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: >> On 2014/4/24 上午 02:15, Pinski, Andrew wrote: >> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" wrote: >> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: >> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >> Hi Arnd and Peter Anvin, >> >> Other than 64-bit time_t, clock_t and suseconds_t, can you >> confirm >> that we don't need to have 64 bit off_t? See detail in link >> below. >> I can submit the patches for 64-bit time changes >> (include/asm-generic/posix_types.h and other archs) if >> everyone is >> agreed on this. >> >> Yes. >> Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? >> Not yet. I am still working out the signal handling part. But we >> already agreed on 64bit time_t, clock_t, and suseconds_t. And we >> agreed to a 64bit offset_t too. >> >> On a related note suseconds in the timespec in posix is defined to >> be long. So it would nice if the kernel ignores the upper 32bits so >> we (glibc developers) can fix this for new targets including x32 >> and arm64/ilp32. > > Hmm, but that means for purely 32-bit architectures like nios2, which > unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit > type in the kernel is simply wasted. The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. >>> >>> ILP32 mode should use LP64 syscalls as much as possible and that's the >>> aim with arm64 as well (of course, we still have a few that wouldn't be >>> possible and we route them via compat). >>> >>> But here if time_t is 64-bit while susecconds_t is 32-bit, the compat >>> code wouldn't help. >> >> Why not? You can define the arm64 'struct compat_timeval' with >> suseconds_t as s32, and add the 32<-->64 case in the >> compat_get/put_timeval path, triggered when the process is ILP32 (test >> wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). >> Similar to how x32 does COMPAT_USE_64BIT_TIME. > > We would three timeval then. One for aarch32, one for lp64 and one for ilp32. > We really don't want three. Two is already one too many in my mind after > developing the ilp32 syscall abi. > > Thanks, > Andrew Okay I now see you're already doing that for 32-bit ARM. Still, you would probably just need to have an arm64-ILP32 specific case to be careful about the last padding word upon kernel entry/exit. (accommodating the difference in sizeof(long)) Penalizing all architectures does not seem like the best solution. Having suseconds_t as a strictly 64-bit C type in the kernel, while defined as <= long in user-space may cause other problems. I'll try to explain a probable situation for Nios II. I'm not sure about other soft-cores, but nios2 is sort of uncommon in that the maximum alignment is 4-bytes (32-bits), even for doubles/long-longs. So if time_t is 64-bits (which makes sense), then struct timeval, which is time_t+suseconds_t in userspace is 12-bytes/aligned-4 (unlike many archs where a 64-bit time_t will expand the size to 16-bytes, due to align-8) If the kernel suseconds_t is forced to be 64-bits, then nios2 will have a 16-byte kernel timeval vs. 12-byte userspace timeval situation. Just this will require us to do something using compat_*, or weird hacks in glibc, which is unfair. Nios II has no "other-mode". We are just strictly ILP32, everywhere. Of course, we can probably still at the end just use a Nios II specific posix_types.h header to override things, but I'm just stating this as a matter of which are the most reasonable default settings in the generic headers. Making pure ILP32 archs diverge from POSIX standards by default does not seem to be right. Thanks, Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/25 02:42 AM, Pinski, Andrew wrote: On Apr 24, 2014, at 11:37 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/24 11:28 PM, Catalin Marinas wrote: On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32--64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. We would three timeval then. One for aarch32, one for lp64 and one for ilp32. We really don't want three. Two is already one too many in my mind after developing the ilp32 syscall abi. Thanks, Andrew Okay I now see you're already doing that for 32-bit ARM. Still, you would probably just need to have an arm64-ILP32 specific case to be careful about the last padding word upon kernel entry/exit. (accommodating the difference in sizeof(long)) Penalizing all architectures does not seem like the best solution. Having suseconds_t as a strictly 64-bit C type in the kernel, while defined as = long in user-space may cause other problems. I'll try to explain a probable situation for Nios II. I'm not sure about other soft-cores, but nios2 is sort of uncommon in that the maximum alignment is 4-bytes (32-bits), even for doubles/long-longs. So if time_t is 64-bits (which makes sense), then struct timeval, which is time_t+suseconds_t in userspace is 12-bytes/aligned-4 (unlike many archs where a 64-bit time_t will expand the size to 16-bytes, due to align-8) If the kernel suseconds_t is forced to be 64-bits, then nios2 will have a 16-byte kernel timeval vs. 12-byte userspace timeval situation. Just this will require us to do something using compat_*, or weird hacks in glibc, which is unfair. Nios II has no other-mode. We are just strictly ILP32, everywhere. Of course, we can probably still at the end just use a Nios II specific posix_types.h header to override things, but I'm just stating this as a matter of which are the most reasonable default settings in the generic headers. Making pure ILP32 archs diverge from POSIX standards by default does not seem to be right. Thanks, Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Apr 24, 2014, at 11:06 PM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/25 02:42 AM, Pinski, Andrew wrote: On Apr 24, 2014, at 11:37 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/24 11:28 PM, Catalin Marinas wrote: On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32--64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. We would three timeval then. One for aarch32, one for lp64 and one for ilp32. We really don't want three. Two is already one too many in my mind after developing the ilp32 syscall abi. Thanks, Andrew Okay I now see you're already doing that for 32-bit ARM. Still, you would probably just need to have an arm64-ILP32 specific case to be careful about the last padding word upon kernel entry/exit. (accommodating the difference in sizeof(long)) Penalizing all architectures does not seem like the best solution. Considering the alignment of long long would be 64bits, the struct does not change sizes if suseconds_t is 32bits or 64bits. Having suseconds_t as a strictly 64-bit C type in the kernel, while defined as = long in user-space may cause other problems. I'll try to explain a probable situation for Nios II. I'm not sure about other soft-cores, but nios2 is sort of uncommon in that the maximum alignment is 4-bytes (32-bits), even for doubles/long-longs. Yes does that include even if users of aligned? If so that seems broken. Also yes nios ii is unstandard when it comes to alignment here. So if time_t is 64-bits (which makes sense), then struct timeval, which is time_t+suseconds_t in userspace is 12-bytes/aligned-4 (unlike many archs where a 64-bit time_t will expand the size to 16-bytes, due to align-8) Unlike most other targets where the struct would 16bits no matter what. Thanks, Andrew If the kernel suseconds_t is forced to be 64-bits, then nios2 will have a 16-byte kernel timeval vs. 12-byte userspace timeval situation. Just this will require us to do something using compat_*, or weird hacks in glibc, which is unfair. Nios II has no other-mode. We are just strictly ILP32, everywhere. Of course, we can probably still at the end just use a Nios II specific posix_types.h header to override things, but I'm just stating this as a matter of which are the most reasonable default settings in the generic headers. Making pure ILP32 archs diverge from POSIX standards by default does not seem to be right. Thanks, Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Fri, Apr 25, 2014 at 8:06 AM, Chung-Lin Tang clt...@codesourcery.com wrote:
I'll try to explain a probable situation for Nios II. I'm not sure about
other soft-cores, but nios2 is sort of uncommon in that the maximum
alignment is 4-bytes (32-bits), even for doubles/long-longs.
FWIW, that's the same as on m32r. And on m68k it's 2 bytes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 14/4/25 下午4:37, Pinski, Andrew wrote: On Apr 24, 2014, at 11:06 PM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/25 02:42 AM, Pinski, Andrew wrote: On Apr 24, 2014, at 11:37 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/24 11:28 PM, Catalin Marinas wrote: On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32--64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. We would three timeval then. One for aarch32, one for lp64 and one for ilp32. We really don't want three. Two is already one too many in my mind after developing the ilp32 syscall abi. Thanks, Andrew Okay I now see you're already doing that for 32-bit ARM. Still, you would probably just need to have an arm64-ILP32 specific case to be careful about the last padding word upon kernel entry/exit. (accommodating the difference in sizeof(long)) Penalizing all architectures does not seem like the best solution. Considering the alignment of long long would be 64bits, the struct does not change sizes if suseconds_t is 32bits or 64bits. Having suseconds_t as a strictly 64-bit C type in the kernel, while defined as = long in user-space may cause other problems. I'll try to explain a probable situation for Nios II. I'm not sure about other soft-cores, but nios2 is sort of uncommon in that the maximum alignment is 4-bytes (32-bits), even for doubles/long-longs. Yes does that include even if users of aligned? If so that seems broken. Also yes nios ii is unstandard when it comes to alignment here. You mean using '__attribute__((aligned(8)))'? Sure of course that enlarges the alignment as expected, but sprinkling that over glibc, or getting it into the main glibc bits/time.h header is probably not going to happen... Thanks, Chung-Lin So if time_t is 64-bits (which makes sense), then struct timeval, which is time_t+suseconds_t in userspace is 12-bytes/aligned-4 (unlike many archs where a 64-bit time_t will expand the size to 16-bytes, due to align-8) Unlike most other targets where the struct would 16bits no matter what. Thanks, Andrew If the kernel suseconds_t is forced to be 64-bits, then nios2 will have a 16-byte kernel timeval vs. 12-byte userspace timeval situation. Just this will require us to do something using compat_*, or weird hacks in glibc, which is unfair. Nios II has no other-mode. We are just strictly ILP32, everywhere. Of course, we can probably still at the end just use a Nios II specific posix_types.h header to override things, but I'm just stating this as a matter of which are the most reasonable default settings in the generic headers. Making pure ILP32 archs diverge from POSIX standards by default does not seem to be right. Thanks, Chung-Lin -- To unsubscribe from this list: send the line
Re: [PATCH 00/28] nios2 Linux kernel port
> On Apr 24, 2014, at 11:37 AM, "Chung-Lin Tang" > wrote: > >> On 2014/4/24 11:28 PM, Catalin Marinas wrote: >>> On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: > On 2014/4/24 上午 02:15, Pinski, Andrew wrote: > >>> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" >>> wrote: >>> > On 2014/4/22 07:20 PM, Ley Foon Tan wrote: > On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: > On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: > Hi Arnd and Peter Anvin, > > Other than 64-bit time_t, clock_t and suseconds_t, can you > confirm > that we don't need to have 64 bit off_t? See detail in link > below. > I can submit the patches for 64-bit time changes > (include/asm-generic/posix_types.h and other archs) if > everyone is > agreed on this. > > Yes. > Okay, will doing that. >>> >>> I believe that arm64 ILP32 will also be affected. What is the status of >>> this configuration? Has the glibc/kernel ABI been finalized? > Not yet. I am still working out the signal handling part. But we > already agreed on 64bit time_t, clock_t, and suseconds_t. And we > agreed to a 64bit offset_t too. > > On a related note suseconds in the timespec in posix is defined to > be long. So it would nice if the kernel ignores the upper 32bits so > we (glibc developers) can fix this for new targets including x32 > and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. >>> >>> The more I think of this, the more I feel that suseconds_t should jsut >>> be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit >>> kernel should be using compat_* code paths, something like a >>> COMPAT_USE_32BIT_SUSECONDS case. >> >> ILP32 mode should use LP64 syscalls as much as possible and that's the >> aim with arm64 as well (of course, we still have a few that wouldn't be >> possible and we route them via compat). >> >> But here if time_t is 64-bit while susecconds_t is 32-bit, the compat >> code wouldn't help. > > Why not? You can define the arm64 'struct compat_timeval' with > suseconds_t as s32, and add the 32<-->64 case in the > compat_get/put_timeval path, triggered when the process is ILP32 (test > wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). > Similar to how x32 does COMPAT_USE_64BIT_TIME. We would three timeval then. One for aarch32, one for lp64 and one for ilp32. We really don't want three. Two is already one too many in my mind after developing the ilp32 syscall abi. Thanks, Andrew > > Chung-Lin > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 11:28 PM, Catalin Marinas wrote: > On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: >> On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: >>> On 2014/4/24 上午 02:15, Pinski, Andrew wrote: >> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" >> wrote: >> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. >> >> I believe that arm64 ILP32 will also be affected. What is the status of >> this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. >>> >>> Hmm, but that means for purely 32-bit architectures like nios2, which >>> unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit >>> type in the kernel is simply wasted. >> >> The more I think of this, the more I feel that suseconds_t should jsut >> be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit >> kernel should be using compat_* code paths, something like a >> COMPAT_USE_32BIT_SUSECONDS case. > > ILP32 mode should use LP64 syscalls as much as possible and that's the > aim with arm64 as well (of course, we still have a few that wouldn't be > possible and we route them via compat). > > But here if time_t is 64-bit while susecconds_t is 32-bit, the compat > code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32<-->64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: > On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: > > On 2014/4/24 上午 02:15, Pinski, Andrew wrote: > >> > On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" > wrote: > > >> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: > >> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: > >> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: > >> Hi Arnd and Peter Anvin, > >> > >> Other than 64-bit time_t, clock_t and suseconds_t, can you > >> confirm > >> that we don't need to have 64 bit off_t? See detail in link > >> below. > >> I can submit the patches for 64-bit time changes > >> (include/asm-generic/posix_types.h and other archs) if > >> everyone is > >> agreed on this. > >> > >> Yes. > >> Okay, will doing that. > > I believe that arm64 ILP32 will also be affected. What is the status of > this configuration? Has the glibc/kernel ABI been finalized? > >> Not yet. I am still working out the signal handling part. But we > >> already agreed on 64bit time_t, clock_t, and suseconds_t. And we > >> agreed to a 64bit offset_t too. > >> > >> On a related note suseconds in the timespec in posix is defined to > >> be long. So it would nice if the kernel ignores the upper 32bits so > >> we (glibc developers) can fix this for new targets including x32 > >> and arm64/ilp32. > > > > Hmm, but that means for purely 32-bit architectures like nios2, which > > unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit > > type in the kernel is simply wasted. > > The more I think of this, the more I feel that suseconds_t should jsut > be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit > kernel should be using compat_* code paths, something like a > COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: > On 2014/4/24 上午 02:15, Pinski, Andrew wrote: >> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" wrote: >> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: >> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >> Hi Arnd and Peter Anvin, >> >> Other than 64-bit time_t, clock_t and suseconds_t, can you >> confirm >> that we don't need to have 64 bit off_t? See detail in link >> below. >> I can submit the patches for 64-bit time changes >> (include/asm-generic/posix_types.h and other archs) if everyone >> is >> agreed on this. >> >> Yes. >> Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? >> Not yet. I am still working out the signal handling part. But we already >> agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit >> offset_t too. >> >> On a related note suseconds in the timespec in posix is defined to be long. >> So it would nice if the kernel ignores the upper 32bits so we (glibc >> developers) can fix this for new targets including x32 and arm64/ilp32. > > Hmm, but that means for purely 32-bit architectures like nios2, which > unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit > type in the kernel is simply wasted. > > Chung-Lin The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. suseconds_t is for micro-seconds in struct timeval, 32-bit is more than enough. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 上午 02:15, Pinski, Andrew wrote: > >> > On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" >> > wrote: >> > >>> >> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >>> >> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: > On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>> >> Hi Arnd and Peter Anvin, >>> >> >>> >> Other than 64-bit time_t, clock_t and suseconds_t, can you >>> >> confirm >>> >> that we don't need to have 64 bit off_t? See detail in link >>> >> below. >>> >> I can submit the patches for 64-bit time changes >>> >> (include/asm-generic/posix_types.h and other archs) if everyone >>> >> is >>> >> agreed on this. > > Yes. >>> >> Okay, will doing that. >> > >> > I believe that arm64 ILP32 will also be affected. What is the status of >> > this configuration? Has the glibc/kernel ABI been finalized? > Not yet. I am still working out the signal handling part. But we already > agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit > offset_t too. > > On a related note suseconds in the timespec in posix is defined to be long. > So it would nice if the kernel ignores the upper 32bits so we (glibc > developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. Chung-Lin The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. suseconds_t is for micro-seconds in struct timeval, 32-bit is more than enough. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 11:28 PM, Catalin Marinas wrote: On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32--64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Apr 24, 2014, at 11:37 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/24 11:28 PM, Catalin Marinas wrote: On Thu, Apr 24, 2014 at 09:55:25AM +0100, Chung-Lin Tang wrote: On 2014/4/24 02:26 PM, Chung-Lin Tang wrote: On 2014/4/24 上午 02:15, Pinski, Andrew wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. The more I think of this, the more I feel that suseconds_t should jsut be 'long', not strictly 64-bitified. An ILP32 sub-mode in a 64-bit kernel should be using compat_* code paths, something like a COMPAT_USE_32BIT_SUSECONDS case. ILP32 mode should use LP64 syscalls as much as possible and that's the aim with arm64 as well (of course, we still have a few that wouldn't be possible and we route them via compat). But here if time_t is 64-bit while susecconds_t is 32-bit, the compat code wouldn't help. Why not? You can define the arm64 'struct compat_timeval' with suseconds_t as s32, and add the 32--64 case in the compat_get/put_timeval path, triggered when the process is ILP32 (test wrapped in the above hypothetical COMPAT_USE_32BIT_SUSECONDS macro). Similar to how x32 does COMPAT_USE_64BIT_TIME. We would three timeval then. One for aarch32, one for lp64 and one for ilp32. We really don't want three. Two is already one too many in my mind after developing the ilp32 syscall abi. Thanks, Andrew Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
I think Linuxs said we should just fix POSIX on that front. On April 23, 2014 11:15:34 AM PDT, "Pinski, Andrew" wrote: > > >> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" > wrote: >> >>> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >>> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann >wrote: > On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>> Hi Arnd and Peter Anvin, >>> >>> Other than 64-bit time_t, clock_t and suseconds_t, can you >confirm >>> that we don't need to have 64 bit off_t? See detail in link >below. >>> I can submit the patches for 64-bit time changes >>> (include/asm-generic/posix_types.h and other archs) if everyone >is >>> agreed on this. > > Yes. >>> Okay, will doing that. >> >> I believe that arm64 ILP32 will also be affected. What is the status >of >> this configuration? Has the glibc/kernel ABI been finalized? > >Not yet. I am still working out the signal handling part. But we >already agreed on 64bit time_t, clock_t, and suseconds_t. And we >agreed to a 64bit offset_t too. > >On a related note suseconds in the timespec in posix is defined to be >long. So it would nice if the kernel ignores the upper 32bits so we >(glibc developers) can fix this for new targets including x32 and >arm64/ilp32. > >Thanks, >Andrew > >> >> Thanks, >> Chung-Lin >> -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
> On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" > wrote: > >> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >> Hi Arnd and Peter Anvin, >> >> Other than 64-bit time_t, clock_t and suseconds_t, can you confirm >> that we don't need to have 64 bit off_t? See detail in link below. >> I can submit the patches for 64-bit time changes >> (include/asm-generic/posix_types.h and other archs) if everyone is >> agreed on this. Yes. >> Okay, will doing that. > > I believe that arm64 ILP32 will also be affected. What is the status of > this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Thanks, Andrew > > Thanks, > Chung-Lin > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/22 07:20 PM, Ley Foon Tan wrote: > On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: >> > On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>> >> Hi Arnd and Peter Anvin, >>> >> >>> >> Other than 64-bit time_t, clock_t and suseconds_t, can you confirm >>> >> that we don't need to have 64 bit off_t? See detail in link below. >>> >> I can submit the patches for 64-bit time changes >>> >> (include/asm-generic/posix_types.h and other archs) if everyone is >>> >> agreed on this. >> > >> > Yes. > Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Thanks, Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Thanks, Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Thanks, Andrew Thanks, Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
I think Linuxs said we should just fix POSIX on that front. On April 23, 2014 11:15:34 AM PDT, Pinski, Andrew andrew.pin...@caviumnetworks.com wrote: On Apr 23, 2014, at 10:59 AM, Chung-Lin Tang clt...@codesourcery.com wrote: On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. I believe that arm64 ILP32 will also be affected. What is the status of this configuration? Has the glibc/kernel ABI been finalized? Not yet. I am still working out the signal handling part. But we already agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit offset_t too. On a related note suseconds in the timespec in posix is defined to be long. So it would nice if the kernel ignores the upper 32bits so we (glibc developers) can fix this for new targets including x32 and arm64/ilp32. Thanks, Andrew Thanks, Chung-Lin -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/22 07:20 PM, Ley Foon Tan wrote: > On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: >> On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>> Hi Arnd and Peter Anvin, >>> >>> Other than 64-bit time_t, clock_t and suseconds_t, can you confirm >>> that we don't need to have 64 bit off_t? See detail in link below. >>> I can submit the patches for 64-bit time changes >>> (include/asm-generic/posix_types.h and other archs) if everyone is >>> agreed on this. >> >> Yes. > Okay, will doing that. > >> >>> Excerpt from https://lkml.org/lkml/2012/11/14/358 : >>> "Obviously, we want to use 64-bit off_t, but this is achieved already >>> through loff_t, which is used in all places in the asm-generic >>> ABI anyway (the syscalls using off_t are stripped out). I don't >>> think we want to have the other ones set to 64 bit on ARC or Meta, >>> although I'm not 100% sure about ino_t and nlink_t. " >> >> This is all still true. You should have no syscall using 'off_t', >> only loff_t. >> >> I still don't know whether we would want 32 or 64 bit ino_t and nlink_t >> for new architectures. It seems it would gain very little, but have >> a noticeable overhead. > Anyone have comment on this? > Chung-Lin (in CC list) is our nios2 toolchain maintainer. Do you have > any comment for 32 or 64 bit ino_t and nlink_t? > We will update the toolchain to support 64-bit time_t, so we hope that > any other toolchain change can happen in one time. For ino_t, 32-bit users of linux-generic glibc already use struct stat64, stat64(), etc. to align with 64-bit targets, so in terms of the glibc/kernel interface it doesn't matter much. The in-kernel usage of the ino_t type should be of more concern here. nlink_t appears to be always defined as u32 in , not sure if changing it to arch-overridable is reasonable. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: > On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >> Hi Arnd and Peter Anvin, >> >> Other than 64-bit time_t, clock_t and suseconds_t, can you confirm >> that we don't need to have 64 bit off_t? See detail in link below. >> I can submit the patches for 64-bit time changes >> (include/asm-generic/posix_types.h and other archs) if everyone is >> agreed on this. > > Yes. Okay, will doing that. > >> Excerpt from https://lkml.org/lkml/2012/11/14/358 : >> "Obviously, we want to use 64-bit off_t, but this is achieved already >> through loff_t, which is used in all places in the asm-generic >> ABI anyway (the syscalls using off_t are stripped out). I don't >> think we want to have the other ones set to 64 bit on ARC or Meta, >> although I'm not 100% sure about ino_t and nlink_t. " > > This is all still true. You should have no syscall using 'off_t', > only loff_t. > > I still don't know whether we would want 32 or 64 bit ino_t and nlink_t > for new architectures. It seems it would gain very little, but have > a noticeable overhead. Anyone have comment on this? Chung-Lin (in CC list) is our nios2 toolchain maintainer. Do you have any comment for 32 or 64 bit ino_t and nlink_t? We will update the toolchain to support 64-bit time_t, so we hope that any other toolchain change can happen in one time. Thanks Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: > Hi Arnd and Peter Anvin, > > Other than 64-bit time_t, clock_t and suseconds_t, can you confirm > that we don't need to have 64 bit off_t? See detail in link below. > I can submit the patches for 64-bit time changes > (include/asm-generic/posix_types.h and other archs) if everyone is > agreed on this. Yes. > Excerpt from https://lkml.org/lkml/2012/11/14/358 : > "Obviously, we want to use 64-bit off_t, but this is achieved already > through loff_t, which is used in all places in the asm-generic > ABI anyway (the syscalls using off_t are stripped out). I don't > think we want to have the other ones set to 64 bit on ARC or Meta, > although I'm not 100% sure about ino_t and nlink_t. " This is all still true. You should have no syscall using 'off_t', only loff_t. I still don't know whether we would want 32 or 64 bit ino_t and nlink_t for new architectures. It seems it would gain very little, but have a noticeable overhead. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Excerpt from https://lkml.org/lkml/2012/11/14/358 : "Obviously, we want to use 64-bit off_t, but this is achieved already through loff_t, which is used in all places in the asm-generic ABI anyway (the syscalls using off_t are stripped out). I don't think we want to have the other ones set to 64 bit on ARC or Meta, although I'm not 100% sure about ino_t and nlink_t. " Thanks. Regards Ley Foon On Mon, Apr 21, 2014 at 1:31 PM, H. Peter Anvin wrote: > On 04/20/2014 10:23 PM, Ley Foon Tan wrote: >> On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann wrote: >>> On Friday 18 April 2014, H. Peter Anvin wrote: Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? >>> >>> No, unfortunately not. With my rule that every architecture that gets >>> added needs to clean up asm-generic some more, to make it easier to add >>> the next one, we should probably do for nios2. >>> >>> Arnd >> >> Can you give me the documentation on this new guidance and point me >> any architecture have implemented this? >> Thanks. >> > > We implemented it in the x32 ABI for x86. In generic code this is keyed > by COMPAT_USE_64BIT_TIME, but in your case it isn't actually a matter of > compat, so it should be easier. > > See this thread including the discussion about time_t: > > https://lkml.org/lkml/2011/8/26/415 > > -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Excerpt from https://lkml.org/lkml/2012/11/14/358 : Obviously, we want to use 64-bit off_t, but this is achieved already through loff_t, which is used in all places in the asm-generic ABI anyway (the syscalls using off_t are stripped out). I don't think we want to have the other ones set to 64 bit on ARC or Meta, although I'm not 100% sure about ino_t and nlink_t. Thanks. Regards Ley Foon On Mon, Apr 21, 2014 at 1:31 PM, H. Peter Anvin h...@zytor.com wrote: On 04/20/2014 10:23 PM, Ley Foon Tan wrote: On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 18 April 2014, H. Peter Anvin wrote: Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? No, unfortunately not. With my rule that every architecture that gets added needs to clean up asm-generic some more, to make it easier to add the next one, we should probably do for nios2. Arnd Can you give me the documentation on this new guidance and point me any architecture have implemented this? Thanks. We implemented it in the x32 ABI for x86. In generic code this is keyed by COMPAT_USE_64BIT_TIME, but in your case it isn't actually a matter of compat, so it should be easier. See this thread including the discussion about time_t: https://lkml.org/lkml/2011/8/26/415 -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Excerpt from https://lkml.org/lkml/2012/11/14/358 : Obviously, we want to use 64-bit off_t, but this is achieved already through loff_t, which is used in all places in the asm-generic ABI anyway (the syscalls using off_t are stripped out). I don't think we want to have the other ones set to 64 bit on ARC or Meta, although I'm not 100% sure about ino_t and nlink_t. This is all still true. You should have no syscall using 'off_t', only loff_t. I still don't know whether we would want 32 or 64 bit ino_t and nlink_t for new architectures. It seems it would gain very little, but have a noticeable overhead. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. Excerpt from https://lkml.org/lkml/2012/11/14/358 : Obviously, we want to use 64-bit off_t, but this is achieved already through loff_t, which is used in all places in the asm-generic ABI anyway (the syscalls using off_t are stripped out). I don't think we want to have the other ones set to 64 bit on ARC or Meta, although I'm not 100% sure about ino_t and nlink_t. This is all still true. You should have no syscall using 'off_t', only loff_t. I still don't know whether we would want 32 or 64 bit ino_t and nlink_t for new architectures. It seems it would gain very little, but have a noticeable overhead. Anyone have comment on this? Chung-Lin (in CC list) is our nios2 toolchain maintainer. Do you have any comment for 32 or 64 bit ino_t and nlink_t? We will update the toolchain to support 64-bit time_t, so we hope that any other toolchain change can happen in one time. Thanks Regards Ley Foon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/22 07:20 PM, Ley Foon Tan wrote: On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: Hi Arnd and Peter Anvin, Other than 64-bit time_t, clock_t and suseconds_t, can you confirm that we don't need to have 64 bit off_t? See detail in link below. I can submit the patches for 64-bit time changes (include/asm-generic/posix_types.h and other archs) if everyone is agreed on this. Yes. Okay, will doing that. Excerpt from https://lkml.org/lkml/2012/11/14/358 : Obviously, we want to use 64-bit off_t, but this is achieved already through loff_t, which is used in all places in the asm-generic ABI anyway (the syscalls using off_t are stripped out). I don't think we want to have the other ones set to 64 bit on ARC or Meta, although I'm not 100% sure about ino_t and nlink_t. This is all still true. You should have no syscall using 'off_t', only loff_t. I still don't know whether we would want 32 or 64 bit ino_t and nlink_t for new architectures. It seems it would gain very little, but have a noticeable overhead. Anyone have comment on this? Chung-Lin (in CC list) is our nios2 toolchain maintainer. Do you have any comment for 32 or 64 bit ino_t and nlink_t? We will update the toolchain to support 64-bit time_t, so we hope that any other toolchain change can happen in one time. For ino_t, 32-bit users of linux-generic glibc already use struct stat64, stat64(), etc. to align with 64-bit targets, so in terms of the glibc/kernel interface it doesn't matter much. The in-kernel usage of the ino_t type should be of more concern here. nlink_t appears to be always defined as u32 in linux/types.h, not sure if changing it to arch-overridable is reasonable. Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 14/4/21 1:31 PM, H. Peter Anvin wrote: > On 04/20/2014 10:23 PM, Ley Foon Tan wrote: >> On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann wrote: >>> On Friday 18 April 2014, H. Peter Anvin wrote: Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? >>> >>> No, unfortunately not. With my rule that every architecture that gets >>> added needs to clean up asm-generic some more, to make it easier to add >>> the next one, we should probably do for nios2. >>> >>> Arnd >> >> Can you give me the documentation on this new guidance and point me >> any architecture have implemented this? >> Thanks. >> > > We implemented it in the x32 ABI for x86. In generic code this is keyed > by COMPAT_USE_64BIT_TIME, but in your case it isn't actually a matter of > compat, so it should be easier. > > See this thread including the discussion about time_t: > > https://lkml.org/lkml/2011/8/26/415 > > -hpa I'm not sure why we need CONFIG_USE_64BIT_TIME? We don't have any 32-on-64 problems. My understanding of what Arnd meant, was to clean up asm-generic/posix_types.h such that for example, time_t should be defined as a 'long long' type, which should be 64-bit almost everywhere. At least AFAIK, that should work for all current asm-generic users. Thanks, Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 14/4/21 1:31 PM, H. Peter Anvin wrote: On 04/20/2014 10:23 PM, Ley Foon Tan wrote: On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 18 April 2014, H. Peter Anvin wrote: Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? No, unfortunately not. With my rule that every architecture that gets added needs to clean up asm-generic some more, to make it easier to add the next one, we should probably do for nios2. Arnd Can you give me the documentation on this new guidance and point me any architecture have implemented this? Thanks. We implemented it in the x32 ABI for x86. In generic code this is keyed by COMPAT_USE_64BIT_TIME, but in your case it isn't actually a matter of compat, so it should be easier. See this thread including the discussion about time_t: https://lkml.org/lkml/2011/8/26/415 -hpa I'm not sure why we need CONFIG_USE_64BIT_TIME? We don't have any 32-on-64 problems. My understanding of what Arnd meant, was to clean up asm-generic/posix_types.h such that for example, time_t should be defined as a 'long long' type, which should be 64-bit almost everywhere. At least AFAIK, that should work for all current asm-generic users. Thanks, Chung-Lin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 04/20/2014 10:23 PM, Ley Foon Tan wrote: > On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann wrote: >> On Friday 18 April 2014, H. Peter Anvin wrote: >>> Did the generic headers ever get updated to match Linus' guidance that >>> any new architecture ports should use a 64-bit time_t? >> >> No, unfortunately not. With my rule that every architecture that gets >> added needs to clean up asm-generic some more, to make it easier to add >> the next one, we should probably do for nios2. >> >> Arnd > > Can you give me the documentation on this new guidance and point me > any architecture have implemented this? > Thanks. > We implemented it in the x32 ABI for x86. In generic code this is keyed by COMPAT_USE_64BIT_TIME, but in your case it isn't actually a matter of compat, so it should be easier. See this thread including the discussion about time_t: https://lkml.org/lkml/2011/8/26/415 -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann wrote: > On Friday 18 April 2014, H. Peter Anvin wrote: >> Did the generic headers ever get updated to match Linus' guidance that >> any new architecture ports should use a 64-bit time_t? > > No, unfortunately not. With my rule that every architecture that gets > added needs to clean up asm-generic some more, to make it easier to add > the next one, we should probably do for nios2. > > Arnd Can you give me the documentation on this new guidance and point me any architecture have implemented this? Thanks. Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 18 April 2014, H. Peter Anvin wrote: Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? No, unfortunately not. With my rule that every architecture that gets added needs to clean up asm-generic some more, to make it easier to add the next one, we should probably do for nios2. Arnd Can you give me the documentation on this new guidance and point me any architecture have implemented this? Thanks. Ley Foon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 04/20/2014 10:23 PM, Ley Foon Tan wrote: On Sat, Apr 19, 2014 at 11:30 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 18 April 2014, H. Peter Anvin wrote: Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? No, unfortunately not. With my rule that every architecture that gets added needs to clean up asm-generic some more, to make it easier to add the next one, we should probably do for nios2. Arnd Can you give me the documentation on this new guidance and point me any architecture have implemented this? Thanks. We implemented it in the x32 ABI for x86. In generic code this is keyed by COMPAT_USE_64BIT_TIME, but in your case it isn't actually a matter of compat, so it should be easier. See this thread including the discussion about time_t: https://lkml.org/lkml/2011/8/26/415 -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Friday 18 April 2014, H. Peter Anvin wrote: > On 04/18/2014 05:26 AM, Ley Foon Tan wrote: > > This patchset adds the Linux kernel port for Nios II processor from Altera. > > The nios2 Linux port follows the guidance for new architecture ports using > > generic headers (including unistd.h). > > Did the generic headers ever get updated to match Linus' guidance that > any new architecture ports should use a 64-bit time_t? No, unfortunately not. With my rule that every architecture that gets added needs to clean up asm-generic some more, to make it easier to add the next one, we should probably do for nios2. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On Friday 18 April 2014, H. Peter Anvin wrote: On 04/18/2014 05:26 AM, Ley Foon Tan wrote: This patchset adds the Linux kernel port for Nios II processor from Altera. The nios2 Linux port follows the guidance for new architecture ports using generic headers (including unistd.h). Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? No, unfortunately not. With my rule that every architecture that gets added needs to clean up asm-generic some more, to make it easier to add the next one, we should probably do for nios2. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 04/18/2014 05:26 AM, Ley Foon Tan wrote: > This patchset adds the Linux kernel port for Nios II processor from Altera. > The nios2 Linux port follows the guidance for new architecture ports using > generic headers (including unistd.h). Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
Okay, I already submitted the remaining 4 patches. Thanks. On Sat, Apr 19, 2014 at 12:49 AM, Ley Foon Tan wrote: > Hi all > > I just found that 4 patches (03/28, 05/28,07/28 and 14/28) are missing > here, because the issue in Git v1.8.3.2. But, the cover letter is correct. > Do I need to resend the whole series (28 patches) or just the missing 4 > patches? > Thanks. > > Regards. > > On Fri, Apr 18, 2014 at 8:26 PM, Ley Foon Tan wrote: >> This patchset adds the Linux kernel port for Nios II processor from Altera. >> The nios2 Linux port follows the guidance for new architecture ports using >> generic headers (including unistd.h). >> >> About Nios II Cores >> --- >> Nios II is a 32-bit embedded-processor architecture designed specifically >> for the >> Altera family of FPGAs. >> More information is available at >> http://www.altera.com/devices/processor/nios2/ni2-index.html >> >> Instruction set and architecture overview documents can be found on the >> following page: >> http://www.altera.com/literature/lit-nio2.jsp >> >> Nios2 GCC port is in mainline and and will be in the FSF 4.9 release. >> >> These patches are also available on this branch: >> git://git.rocketboards.org/linux-socfpga-next.git nios2-upstream >> >> Regards, >> Ley Foon >> -- >> 1.8.3.2 >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
Hi all I just found that 4 patches (03/28, 05/28,07/28 and 14/28) are missing here, because the issue in Git v1.8.3.2. But, the cover letter is correct. Do I need to resend the whole series (28 patches) or just the missing 4 patches? Thanks. Regards. On Fri, Apr 18, 2014 at 8:26 PM, Ley Foon Tan wrote: > This patchset adds the Linux kernel port for Nios II processor from Altera. > The nios2 Linux port follows the guidance for new architecture ports using > generic headers (including unistd.h). > > About Nios II Cores > --- > Nios II is a 32-bit embedded-processor architecture designed specifically for > the > Altera family of FPGAs. > More information is available at > http://www.altera.com/devices/processor/nios2/ni2-index.html > > Instruction set and architecture overview documents can be found on the > following page: > http://www.altera.com/literature/lit-nio2.jsp > > Nios2 GCC port is in mainline and and will be in the FSF 4.9 release. > > These patches are also available on this branch: > git://git.rocketboards.org/linux-socfpga-next.git nios2-upstream > > Regards, > Ley Foon > -- > 1.8.3.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
Hi all I just found that 4 patches (03/28, 05/28,07/28 and 14/28) are missing here, because the issue in Git v1.8.3.2. But, the cover letter is correct. Do I need to resend the whole series (28 patches) or just the missing 4 patches? Thanks. Regards. On Fri, Apr 18, 2014 at 8:26 PM, Ley Foon Tan lf...@altera.com wrote: This patchset adds the Linux kernel port for Nios II processor from Altera. The nios2 Linux port follows the guidance for new architecture ports using generic headers (including unistd.h). About Nios II Cores --- Nios II is a 32-bit embedded-processor architecture designed specifically for the Altera family of FPGAs. More information is available at http://www.altera.com/devices/processor/nios2/ni2-index.html Instruction set and architecture overview documents can be found on the following page: http://www.altera.com/literature/lit-nio2.jsp Nios2 GCC port is in mainline and and will be in the FSF 4.9 release. These patches are also available on this branch: git://git.rocketboards.org/linux-socfpga-next.git nios2-upstream Regards, Ley Foon -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
Okay, I already submitted the remaining 4 patches. Thanks. On Sat, Apr 19, 2014 at 12:49 AM, Ley Foon Tan lf...@altera.com wrote: Hi all I just found that 4 patches (03/28, 05/28,07/28 and 14/28) are missing here, because the issue in Git v1.8.3.2. But, the cover letter is correct. Do I need to resend the whole series (28 patches) or just the missing 4 patches? Thanks. Regards. On Fri, Apr 18, 2014 at 8:26 PM, Ley Foon Tan lf...@altera.com wrote: This patchset adds the Linux kernel port for Nios II processor from Altera. The nios2 Linux port follows the guidance for new architecture ports using generic headers (including unistd.h). About Nios II Cores --- Nios II is a 32-bit embedded-processor architecture designed specifically for the Altera family of FPGAs. More information is available at http://www.altera.com/devices/processor/nios2/ni2-index.html Instruction set and architecture overview documents can be found on the following page: http://www.altera.com/literature/lit-nio2.jsp Nios2 GCC port is in mainline and and will be in the FSF 4.9 release. These patches are also available on this branch: git://git.rocketboards.org/linux-socfpga-next.git nios2-upstream Regards, Ley Foon -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/28] nios2 Linux kernel port
On 04/18/2014 05:26 AM, Ley Foon Tan wrote: This patchset adds the Linux kernel port for Nios II processor from Altera. The nios2 Linux port follows the guidance for new architecture ports using generic headers (including unistd.h). Did the generic headers ever get updated to match Linus' guidance that any new architecture ports should use a 64-bit time_t? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
