On Monday 19 May 2014 18:12:18 Joseph S. Myers wrote:
> On Mon, 19 May 2014, Arnd Bergmann wrote:
>
> > A related question would be how you plan to support future CPU architectures
> > that never had the 32-bit time_t in the kernel ABI. Would you also want
> > to provide both 32 and 64 bit time_t
On Mon, 19 May 2014, Arnd Bergmann wrote:
> A related question would be how you plan to support future CPU architectures
> that never had the 32-bit time_t in the kernel ABI. Would you also want
> to provide both 32 and 64 bit time_t to user space on those?
I'd expect those just to have 64-bit ti
On Monday 19 May 2014 14:46:59 Joseph S. Myers wrote:
> On Mon, 19 May 2014, Arnd Bergmann wrote:
>
> Now, when the motivation is not space reduction but ensuring nothing is
> there that will break in 2038 (unless it's doing dubious things like
> storing a time_t value in an int or long in the ap
On Mon, 19 May 2014, Arnd Bergmann wrote:
> I'm mostly worried about the embedded use case, which at least for time_t
> would have to build everything the new way as soon as possible. For
> desktop and server systems, doing a slow migration to catch the bugs
> and never introduce regressions in th
On Thursday 15 May 2014 21:05:03 Joseph S. Myers wrote:
> On Thu, 15 May 2014, Arnd Bergmann wrote:
>
> > > The distribution side of the change for _FILE_OFFSET_BITS (i.e., moving
> > > to
> > > building libraries that way so a glibc change to the default wouldn't
> > > cause issues for other l
On Sun, 18 May 2014, H. Peter Anvin wrote:
> This potentially requires the kernel to maintain three separate ABIs if
> there is a legacy 32-bit ABI, which is quite frankly idiotic. You seem
Three ABIs seems reasonable enough to me where appropriate.
> to be thinking of POSIX as something handed
On 05/18/2014 06:46 AM, Joseph S. Myers wrote:
>
> It's advising against breaking compatibility with existing applications
> (in that case, C90 applications that assume sizes can be cast to unsigned
> long for printing, etc.) unless necessary.
>
Yes, the values in question will not be a proble
On Sat, 17 May 2014, H. Peter Anvin wrote:
> > Adding snseconds_t to POSIX seems pointless when there is no need for this
> > field to store values that can't fit in "long". Even if it were added,
> > good practice would say that implementations should keep using "long"
> > whenever possible f
On 05/16/2014 04:47 PM, Joseph S. Myers wrote:
>>
>> struct timespec is specified in POSIX as having type "long" for tv_nsec.
>> This, as Linus pointed out, is totally braindamaged.
>
> long is a perfectly reasonable type for this purpose - it's guaranteed to
> have enough precision. ISO C11 fo
On Sat, 17 May 2014, H. Peter Anvin wrote:
> On 05/15/2014 01:38 PM, Arnd Bergmann wrote:
> >
> > For practical purposes in the kernel, we may still want to use 64-bit
> > nanoseconds: if we use a 96 bit struct timespec, that would be incompatible
> > with the native type on 64-bit kernels, thus
On 05/15/2014 01:38 PM, Arnd Bergmann wrote:
>
> For practical purposes in the kernel, we may still want to use 64-bit
> nanoseconds: if we use a 96 bit struct timespec, that would be incompatible
> with the native type on 64-bit kernels, thus complicating the syscall
> emulation layer.
>
> I don
On 05/16/2014 12:48 AM, Christoph Hellwig wrote:
>
> The stat(64) syscall already has stopped time_t for a long time:
>
> struct stat64 {
> ...
> int st_atime; /* Time of last access. */
> unsigned intst_atime_nsec;
> int st_mtime;
On Thu, May 15, 2014 at 10:07:17PM +0100, One Thousand Gnomes wrote:
> True sort of for the kernel (except you've got problems with file system
> compatibility and I believe stuff like NFS and that fact some file
> systems just break).
modern filesystems including NFS don't use anything that corre
> > could do intelligent interpolation about what the epoch is, so in 2039
> > if we get a low 32 bit time_t value, we assume epoch == 1, conversely if
> > we see a high one, we assume epoch == 0. We could add epoch on the end
> > of the syscalls and detect if it's not present and fill in an
> > i
On Thu, 15 May 2014, Arnd Bergmann wrote:
> > The distribution side of the change for _FILE_OFFSET_BITS (i.e., moving to
> > building libraries that way so a glibc change to the default wouldn't
> > cause issues for other libraries' ABIs) has gradually been done. The
> > discussion in March on
On Thursday 15 May 2014 20:10:05 Joseph S. Myers wrote:
> On Thu, 15 May 2014, Arnd Bergmann wrote:
>
> > Earlier in the thread there seemed to be a rough consensus that
> > _TIME_BITS=64 wouldn't be a good idea because we wouldn't get everything
> > changed to use it. For _FILE_OFFSET_BITS=64 tha
On Thu, 15 May 2014, Arnd Bergmann wrote:
> Earlier in the thread there seemed to be a rough consensus that
> _TIME_BITS=64 wouldn't be a good idea because we wouldn't get everything
> changed to use it. For _FILE_OFFSET_BITS=64 that's ok because most
> user space doesn't ever want to deal with la
On Thursday 15 May 2014 18:01:37 Joseph S. Myers wrote:
> On Thu, 15 May 2014, Chung-Lin Tang wrote:
>
> > > c) glibc may or may not provide a way for applications to use
> > >the extended interfaces without a user space ABI break. My
> > >impression so far is that this is going to be too
On Thu, 15 May 2014, Chung-Lin Tang wrote:
> > c) glibc may or may not provide a way for applications to use
> >the extended interfaces without a user space ABI break. My
> >impression so far is that this is going to be too hard and
> >it won't be done, but this is for the glibc develo
On 2014/5/15 07:08 PM, Arnd Bergmann wrote:
> On Wednesday 14 May 2014 14:33:18 John Stultz wrote:
>> On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann wrote:
>>> On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote:
On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann wrote:
> Using 64-bit
On 2014/5/15 07:08 PM, Arnd Bergmann wrote:
> On Wednesday 14 May 2014 14:33:18 John Stultz wrote:
>> On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann wrote:
>>> On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote:
On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann wrote:
> Using 64-bit
On Thursday 15 May 2014 11:47:03 James Bottomley wrote:
> On Wed, 2014-05-14 at 13:00 +0200, Arnd Bergmann wrote:
> > On Tuesday 13 May 2014 22:35:08 Geert Uytterhoeven wrote:
> > >
> > > On Tue, May 13, 2014 at 9:32 PM, Arnd Bergmann wrote:
> > > > I think we have three categories:
> > >
> > >
On Wed, 2014-05-14 at 13:00 +0200, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 22:35:08 Geert Uytterhoeven wrote:
> >
> > On Tue, May 13, 2014 at 9:32 PM, Arnd Bergmann wrote:
> > > I think we have three categories:
> >
> > Thanks for the list!
> >
> > > a) interfaces that uses relative time_
On Thu, May 15, 2014 at 01:08:02PM +0200, Arnd Bergmann wrote:
> c) glibc may or may not provide a way for applications to use
>the extended interfaces without a user space ABI break. My
>impression so far is that this is going to be too hard and
>it won't be done, but this is for the g
On Wednesday 14 May 2014 14:33:18 John Stultz wrote:
> On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann wrote:
> > On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote:
> >> On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann wrote:
> >> > Using 64-bit time_t on x32 is fine, because it's fast to op
On Wed, 14 May 2014, H. Peter Anvin wrote:
> On 05/14/2014 02:33 PM, John Stultz wrote:
> >
> > We can do some tricks for internal optimizations here if these are
> > critical. I'd be more concerned about userland divisions where moving
> > to a 64bit time_t would cause performance issues that w
On 05/14/2014 02:33 PM, John Stultz wrote:
>
> We can do some tricks for internal optimizations here if these are
> critical. I'd be more concerned about userland divisions where moving
> to a 64bit time_t would cause performance issues that we cannot help
> optimize.
>
Honestly, the cost of no
On Tue, May 13, 2014 at 12:32 PM, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote:
>> On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann wrote:
>> > Using 64-bit time_t on x32 is fine, because it's fast to operate
>> > in user space with 64-bit registers, and the kerne
On 05/14/2014 03:33 AM, Arnd Bergmann wrote:
>>
>> Hi Arnd,
>>
>> From your comment above, can I assume we don't need this patchset any more?
>
> I won't require it, but it's not just my decision to make.
>
Linus has pushed extremely hard for it, and it *is* his decision to
make. If you want an
On Wednesday 14 May 2014 16:46:29 Thomas Gleixner wrote:
> On Wed, 14 May 2014, Arnd Bergmann wrote:
>
> > On Wednesday 14 May 2014 14:21:48 Thomas Gleixner wrote:
> > >
> > > So in the 32-on-64 case we'll have two compat variants:
> > >
> > > SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op,
On Wed, 14 May 2014, Arnd Bergmann wrote:
> On Wednesday 14 May 2014 14:21:48 Thomas Gleixner wrote:
> >
> > So in the 32-on-64 case we'll have two compat variants:
> >
> > SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
> > struct timespec __user *, utime, u32 __u
On Wednesday 14 May 2014 14:21:48 Thomas Gleixner wrote:
>
> So in the 32-on-64 case we'll have two compat variants:
>
> SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val,
> struct timespec __user *, utime, u32 __user *, uaddr2,
> u32, val3)
>
> COMPAT
On Wed, 14 May 2014, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 22:35:08 Geert Uytterhoeven wrote:
> >
> > On Tue, May 13, 2014 at 9:32 PM, Arnd Bergmann wrote:
> > > I think we have three categories:
> >
> > Thanks for the list!
> >
> > > a) interfaces that uses relative time_t/timespec/tim
On Tuesday 13 May 2014 22:35:08 Geert Uytterhoeven wrote:
>
> On Tue, May 13, 2014 at 9:32 PM, Arnd Bergmann wrote:
> > I think we have three categories:
>
> Thanks for the list!
>
> > a) interfaces that uses relative time_t/timespec/timeval:
> > b) interfaces that don't make sense for times in
On Wednesday 14 May 2014 18:13:41 Ley Foon Tan wrote:
> On Wed, May 14, 2014 at 2:10 AM, Arnd Bergmann wrote:
> > I've just spent two days looking at stuff that uses time_t inside
> > of the kernel, to get a better idea of what we actually need to
> > do to get provide new user interfaces for the
On Wed, May 14, 2014 at 2:10 AM, Arnd Bergmann wrote:
> I've just spent two days looking at stuff that uses time_t inside
> of the kernel, to get a better idea of what we actually need to
> do to get provide new user interfaces for the existing architectures.
>
> My impression so far is that we're
Hi Arnd,
On Tue, May 13, 2014 at 9:32 PM, Arnd Bergmann wrote:
> I think we have three categories:
Thanks for the list!
> a) interfaces that uses relative time_t/timespec/timeval:
> b) interfaces that don't make sense for times in the past:
> c) interfaces that require absolute times:
>- s
On Tuesday 13 May 2014 20:24:59 Geert Uytterhoeven wrote:
> On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann wrote:
> > Using 64-bit time_t on x32 is fine, because it's fast to operate
> > in user space with 64-bit registers, and the kernel is 64-bit
> > anyway. Inside of the kernel, we may get into
On Tue, 13 May 2014, Christoph Hellwig wrote:
> On Tue, May 13, 2014 at 05:33:01PM +0200, Thomas Gleixner wrote:
> > Err, we CANNOT do that. We cannot move ANY 32 bit architecture to
> > 64bit time_t without breaking the world and some more.
>
> Of course we can, we just need to still provide the
On Tue, May 13, 2014 at 8:10 PM, Arnd Bergmann wrote:
> On Tuesday 13 May 2014 10:46:40 Christoph Hellwig wrote:
>> On Tue, May 13, 2014 at 05:33:01PM +0200, Thomas Gleixner wrote:
>> > and it
>> > would be dumb as hell to have new archs use time_t 32bit when we are
>> > currently twisting our bra
On Tue, May 13, 2014 at 7:46 PM, Christoph Hellwig wrote:
>> and it
>> would be dumb as hell to have new archs use time_t 32bit when we are
>> currently twisting our brain around how to solve the y2038
>> problem. Simply because we can not do the BSD flag day approach and
>> change it.
>
> I don't
On Tuesday 13 May 2014 10:46:40 Christoph Hellwig wrote:
> On Tue, May 13, 2014 at 05:33:01PM +0200, Thomas Gleixner wrote:
> > and it
> > would be dumb as hell to have new archs use time_t 32bit when we are
> > currently twisting our brain around how to solve the y2038
> > problem. Simply because
On Tue, May 13, 2014 at 05:33:01PM +0200, Thomas Gleixner wrote:
> Err, we CANNOT do that. We cannot move ANY 32 bit architecture to
> 64bit time_t without breaking the world and some more.
Of course we can, we just need to still provide the existing 32-bit
time_t ABIs for backwards compatiblity.
On Tue, May 13, 2014 at 04:57:36PM +0800, Ley Foon Tan wrote:
> This patchset change default time_t and clock_t to 64 bit in
> include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures
> override
> these define to 32 bit in arch posix_types.h.
>
> There is request to support 64 bi
On Tue, 13 May 2014, Christoph Hellwig wrote:
> On Tue, May 13, 2014 at 04:57:36PM +0800, Ley Foon Tan wrote:
> > This patchset change default time_t and clock_t to 64 bit in
> > include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures
> > override
> > these define to 32 bit in ar
On Tue, May 13, 2014 at 5:10 PM, Geert Uytterhoeven
wrote:
> Hi,
>
> On Tue, May 13, 2014 at 10:57 AM, Ley Foon Tan wrote:
>> This patchset change default time_t and clock_t to 64 bit in
>> include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures
>> override
>> these define to 3
Hi,
On Tue, May 13, 2014 at 10:57 AM, Ley Foon Tan wrote:
> This patchset change default time_t and clock_t to 64 bit in
> include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures
> override
> these define to 32 bit in arch posix_types.h.
Thanks for your series!
> Ley Foon Tan
This patchset change default time_t and clock_t to 64 bit in
include/uapi/asm-generic/posix_types.h. The existing 32 bit architectures
override
these define to 32 bit in arch posix_types.h.
There is request to support 64 bit time_t for new architecture [1]. According
to the
previous discussion w
48 matches
Mail list logo
