Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1671154 > unrolled thread

Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

Back to article view | Back to linux.kernel

Contents

  Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2017-06-20 23:40 +0200
    Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Thomas Gleixner <tglx@linutronix.de> - 2017-06-21 00:10 +0200
      Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-06-21 00:50 +0200
      Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Pavel Machek <pavel@ucw.cz> - 2017-06-21 10:00 +0200
        Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2017-06-21 10:40 +0200
          Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-06-21 11:30 +0200
            Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2017-06-21 11:50 +0200
          Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Pavel Machek <pavel@ucw.cz> - 2017-06-21 13:40 +0200
            Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2017-06-21 14:40 +0200
              Re: [PATCH 00/51] rtc: stop using rtc deprecated functions Pavel Machek <pavel@ucw.cz> - 2017-06-21 20:10 +0200

#1671154 — Re: [PATCH 00/51] rtc: stop using rtc deprecated functions

On 20/06/2017 at 22:15:36 +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote:
> > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni
> > <alexandre.belloni@free-electrons.com>:
> > >> Yes, that's argument against changing rtc _drivers_ for hardware that
> > >> can not do better than 32bit. For generic code (such as 44/51 sysfs,
> > >> 51/51 suspend test), the change still makes sense.
> > 
> > What I had in mind when writing those patches was to remove the limitations
> > coming from those functions usage, even more since they been marked has
> > deprecated.
> 
> I'd say that they should not be marked as deprecated.  They're entirely
> appropriate for use with hardware that only supports a 32-bit
> representation of time.
> 
> It's entirely reasonable to fix the ones that use other representations
> that exceed that, but for those which do not, we need to keep using the
> 32-bit versions.  Doing so actually gives us _more_ flexibility in the
> future.
> 
> Consider that at the moment, we define the 32-bit RTC representation to
> start at a well known epoch.  We _could_ decide that when it wraps to
> 0x80000000 seconds, we'll define the lower 0x40000000 seconds to mean
> dates in the future - and keep rolling that forward each time we cross
> another 0x40000000 seconds.  Unless someone invents a real time machine,
> we shouldn't need to set a modern RTC back to 1970.
> 

I agree with that but not the android guys. They seem to mandate an RTC
that can store time from 01/01/1970. I don't know much more than that
because they never cared to explain why that was actually necessary
(apart from a laconic "this will result in a bad user experience")

I think tglx had a plan for offsetting the time at some point so 32-bit
platform can pass 2038 properly.
My opinion is that as long as userspace is not ready to handle those
dates, it doesn't really matter because it is quite unlikely that
anything will be able to continue running anyway.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [next] | [standalone]

#1671183

On Tue, 20 Jun 2017, Alexandre Belloni wrote:
> On 20/06/2017 at 22:15:36 +0100, Russell King - ARM Linux wrote:
> > On Tue, Jun 20, 2017 at 05:07:46PM +0200, Benjamin Gaignard wrote:
> > > 2017-06-20 15:48 GMT+02:00 Alexandre Belloni
> > > <alexandre.belloni@free-electrons.com>:
> > > >> Yes, that's argument against changing rtc _drivers_ for hardware that
> > > >> can not do better than 32bit. For generic code (such as 44/51 sysfs,
> > > >> 51/51 suspend test), the change still makes sense.
> > > 
> > > What I had in mind when writing those patches was to remove the limitations
> > > coming from those functions usage, even more since they been marked has
> > > deprecated.
> > 
> > I'd say that they should not be marked as deprecated.  They're entirely
> > appropriate for use with hardware that only supports a 32-bit
> > representation of time.
> > 
> > It's entirely reasonable to fix the ones that use other representations
> > that exceed that, but for those which do not, we need to keep using the
> > 32-bit versions.  Doing so actually gives us _more_ flexibility in the
> > future.
> > 
> > Consider that at the moment, we define the 32-bit RTC representation to
> > start at a well known epoch.  We _could_ decide that when it wraps to
> > 0x80000000 seconds, we'll define the lower 0x40000000 seconds to mean
> > dates in the future - and keep rolling that forward each time we cross
> > another 0x40000000 seconds.  Unless someone invents a real time machine,
> > we shouldn't need to set a modern RTC back to 1970.
> > 
> 
> I agree with that but not the android guys. They seem to mandate an RTC
> that can store time from 01/01/1970. I don't know much more than that
> because they never cared to explain why that was actually necessary
> (apart from a laconic "this will result in a bad user experience")
> 
> I think tglx had a plan for offsetting the time at some point so 32-bit
> platform can pass 2038 properly.

Yes, but there are still quite some issues to solve there:

     1) How do you tell the system that it should apply the offset in the
     	first place, i.e at boot time before NTP or any other mechanism can
     	correct it?

     2) Deal with creative vendors who have their own idea about the 'start
     	of the epoch'
	
     3) Add the information of wraparound time to the rtc device which
     	needs to be filled in for each device. That way the rtc_***
     	accessor functions can deal with them whether they wrap in 2038 or
     	2100 or whatever.

#3 is the simplest problem of them :)	

> My opinion is that as long as userspace is not ready to handle those
> dates, it doesn't really matter because it is quite unlikely that
> anything will be able to continue running anyway.

That's a different story. Making the kernel y2038 ready in general is a
good thing. Whether userspace will be ready by then or not is completely
irrelevant.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1671207

On Wed, Jun 21, 2017 at 12:00:30AM +0200, Thomas Gleixner wrote:
> Yes, but there are still quite some issues to solve there:
> 
>      1) How do you tell the system that it should apply the offset in the
>      	first place, i.e at boot time before NTP or any other mechanism can
>      	correct it?
> 
>      2) Deal with creative vendors who have their own idea about the 'start
>      	of the epoch'
> 	
>      3) Add the information of wraparound time to the rtc device which
>      	needs to be filled in for each device. That way the rtc_***
>      	accessor functions can deal with them whether they wrap in 2038 or
>      	2100 or whatever.
> 
> #3 is the simplest problem of them :)	

Well, if there's additional non-volatile storage, you can store
additional information in there, but you still need the RTC
subsystem to be aware that the hardware is only 32-bit capable.

You'd also still need something along the lines I detailed
(redefining what dates the past 32-bit values indicate) to cope
with the RTC being set backwards after the machine thinks (possibly
incorrectly) that the date has jumped forwards.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1671453

[Multipart message — attachments visible in raw view] — view raw

Hi!

> > I agree with that but not the android guys. They seem to mandate an RTC
> > that can store time from 01/01/1970. I don't know much more than that
> > because they never cared to explain why that was actually necessary
> > (apart from a laconic "this will result in a bad user experience")
> > 
> > I think tglx had a plan for offsetting the time at some point so 32-bit
> > platform can pass 2038 properly.
> 
> Yes, but there are still quite some issues to solve there:
> 
>      1) How do you tell the system that it should apply the offset in the
>      	first place, i.e at boot time before NTP or any other mechanism can
>      	correct it?

I'd not do offset. Instead, I'd select a threshold (perhaps year of
release of given kernel?) and

	if (rtc_time < year_of_release_of_kernel)
	   rtc_time += 0x100000000;

Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
seen in some drivers.

>      2) Deal with creative vendors who have their own idea about the 'start
>      	of the epoch'

If someone uses different threshold, well, there will be
confusion. But only for users that have their rtc set to the past,
which is quite unusual.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1671497

On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> Hi!
> 
> > > I agree with that but not the android guys. They seem to mandate an RTC
> > > that can store time from 01/01/1970. I don't know much more than that
> > > because they never cared to explain why that was actually necessary
> > > (apart from a laconic "this will result in a bad user experience")
> > > 
> > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > platform can pass 2038 properly.
> > 
> > Yes, but there are still quite some issues to solve there:
> > 
> >      1) How do you tell the system that it should apply the offset in the
> >      	first place, i.e at boot time before NTP or any other mechanism can
> >      	correct it?
> 
> I'd not do offset. Instead, I'd select a threshold (perhaps year of
> release of given kernel?) and
> 
> 	if (rtc_time < year_of_release_of_kernel)
> 	   rtc_time += 0x100000000;
> 
> Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> seen in some drivers.
> 
> >      2) Deal with creative vendors who have their own idea about the 'start
> >      	of the epoch'
> 
> If someone uses different threshold, well, there will be
> confusion. But only for users that have their rtc set to the past,
> which is quite unusual.
> 

Or not, having an RTC set in the past is actually quite common. I'd find
it weird to have a new device boot and be set to a date in the future.

Also note that the threshold or offset thing may seem like a good idea
but fails with many RTCs because of how they handle leap years.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1671538

On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote:
> On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> > If someone uses different threshold, well, there will be
> > confusion. But only for users that have their rtc set to the past,
> > which is quite unusual.
> > 
> 
> Or not, having an RTC set in the past is actually quite common. I'd find
> it weird to have a new device boot and be set to a date in the future.

... and that basically means you can't use hardware that stores RTC
time as a 32-bit number of seconds past 2106.

> Also note that the threshold or offset thing may seem like a good idea
> but fails with many RTCs because of how they handle leap years.

Not for the case being discussed.  A 32-bit counter of seconds knows
nothing about leap years - all that is handled by the conversion
functions.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[toc] | [prev] | [next] | [standalone]

#1671567

On 21/06/2017 at 10:19:49 +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 21, 2017 at 10:39:07AM +0200, Alexandre Belloni wrote:
> > On 21/06/2017 at 09:51:52 +0200, Pavel Machek wrote:
> > > If someone uses different threshold, well, there will be
> > > confusion. But only for users that have their rtc set to the past,
> > > which is quite unusual.
> > > 
> > 
> > Or not, having an RTC set in the past is actually quite common. I'd find
> > it weird to have a new device boot and be set to a date in the future.
> 
> ... and that basically means you can't use hardware that stores RTC
> time as a 32-bit number of seconds past 2106.
> 

And I guess it will not matter much for us anyway ;)

> > Also note that the threshold or offset thing may seem like a good idea
> > but fails with many RTCs because of how they handle leap years.
> 
> Not for the case being discussed.  A 32-bit counter of seconds knows
> nothing about leap years - all that is handled by the conversion
> functions.
> 

Well, the patch series touches some RTCs that are not using 32 bit
counter so I though I might as well raise the issue now.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1671624

Hi!

> > > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > > platform can pass 2038 properly.
> > > 
> > > Yes, but there are still quite some issues to solve there:
> > > 
> > >      1) How do you tell the system that it should apply the offset in the
> > >      	first place, i.e at boot time before NTP or any other mechanism can
> > >      	correct it?
> > 
> > I'd not do offset. Instead, I'd select a threshold (perhaps year of
> > release of given kernel?) and
> > 
> > 	if (rtc_time < year_of_release_of_kernel)
> > 	   rtc_time += 0x100000000;
> > 
> > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> > seen in some drivers.
> > 
> > >      2) Deal with creative vendors who have their own idea about the 'start
> > >      	of the epoch'
> > 
> > If someone uses different threshold, well, there will be
> > confusion. But only for users that have their rtc set to the past,
> > which is quite unusual.
> > 
> 
> Or not, having an RTC set in the past is actually quite common. I'd find
> it weird to have a new device boot and be set to a date in the future.

...but still better than board stuck in the past, no?

> Also note that the threshold or offset thing may seem like a good idea
> but fails with many RTCs because of how they handle leap years.

Well, you can still convert time from rtc to unix time, then do adjustment
there.

Anyway, I guess it would be cool for rtc drivers to annotate what limits
underlying storage has to the common code, so that we can do fixups once
per class, not once per driver.
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1671649

On 21/06/2017 at 08:34:43 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > I think tglx had a plan for offsetting the time at some point so 32-bit
> > > > > platform can pass 2038 properly.
> > > > 
> > > > Yes, but there are still quite some issues to solve there:
> > > > 
> > > >      1) How do you tell the system that it should apply the offset in the
> > > >      	first place, i.e at boot time before NTP or any other mechanism can
> > > >      	correct it?
> > > 
> > > I'd not do offset. Instead, I'd select a threshold (perhaps year of
> > > release of given kernel?) and
> > > 
> > > 	if (rtc_time < year_of_release_of_kernel)
> > > 	   rtc_time += 0x100000000;
> > > 
> > > Ok, we'll have to move away from "rtc_time == 0 indicates zero", as
> > > seen in some drivers.
> > > 
> > > >      2) Deal with creative vendors who have their own idea about the 'start
> > > >      	of the epoch'
> > > 
> > > If someone uses different threshold, well, there will be
> > > confusion. But only for users that have their rtc set to the past,
> > > which is quite unusual.
> > > 
> > 
> > Or not, having an RTC set in the past is actually quite common. I'd find
> > it weird to have a new device boot and be set to a date in the future.
> 
> ...but still better than board stuck in the past, no?
> 
> > Also note that the threshold or offset thing may seem like a good idea
> > but fails with many RTCs because of how they handle leap years.
> 
> Well, you can still convert time from rtc to unix time, then do adjustment
> there.
> 

You can only if your machine is running when that happens. If that is
not the case, then you lost and your time is not correct anymore.

There is currently one rtc doing that kind of trick but it is used as a
simple time counter from the beginning. Transitioning is the difficult
part.

> Anyway, I guess it would be cool for rtc drivers to annotate what limits
> underlying storage has to the common code, so that we can do fixups once
> per class, not once per driver.

Yes, I'm in the middle of the whole rework that allows that.

I don't understand the sudden urgency of fixing that and the amount of
bikeshedding, seeing that the closest cutoff date is actually 31st of
december 2069 in the rtc subsystem and that anyway the current 32bit
userspace will explode in february 2038.

My plan from the beginning was to have something for the next stable. I
know nobody can read my mind but again, I don't think there is currently
any urgency to change anything.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1671884

[Multipart message — attachments visible in raw view] — view raw

Hi!

> > > Or not, having an RTC set in the past is actually quite common. I'd find
> > > it weird to have a new device boot and be set to a date in the future.
> > 
> > ...but still better than board stuck in the past, no?
> > 
> > > Also note that the threshold or offset thing may seem like a good idea
> > > but fails with many RTCs because of how they handle leap years.
> > 
> > Well, you can still convert time from rtc to unix time, then do adjustment
> > there.
> > 
> 
> You can only if your machine is running when that happens. If that is
> not the case, then you lost and your time is not correct anymore.

I don't see why that should be a case... as long as you know what RTC
does in event of overflow, and it is not something completely crazy.

> > Anyway, I guess it would be cool for rtc drivers to annotate what limits
> > underlying storage has to the common code, so that we can do fixups once
> > per class, not once per driver.
> 
> Yes, I'm in the middle of the whole rework that allows that.
> 
> I don't understand the sudden urgency of fixing that and the amount of
> bikeshedding, seeing that the closest cutoff date is actually 31st of
> december 2069 in the rtc subsystem and that anyway the current 32bit
> userspace will explode in february 2038.
> 
> My plan from the beginning was to have something for the next stable. I
> know nobody can read my mind but again, I don't think there is currently
> any urgency to change anything.

Yes, mind reading is a problem. I can only read minds of ferungulates,
and only if they are physicaly near me :-).

Best regards,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web