[master] Patches for HW clock saving and restoring

Vratislav Podzimek vpodzime at redhat.com
Fri Sep 21 08:14:21 UTC 2012


On Thu, 2012-09-20 at 16:06 -0400, Chris Lumens wrote:
> > I've got this vague worry about adding more threads which depend on
> > other threads. I'm concerned that we're going to hit a point where we
> > start hitting hard to reproduce problems caused by races (or other
> > issues) between interdependent threads. I don't have a solution and not
> > even a concrete description of a problem, just a worry. I'd feel better
> > if there was a non-threaded way to do this.
> 
> Well, there's what we discussed in IRC.  Does this absolutely need to be
> decided on the first hub, or can it be delayed until the progress hub
> where we'll know what the filesystems look like?
> 
> I've probably not been the best role model with thread usage, but I
> think we should try to limit threads to where they are absolutely
> necessary.  I hope here we can just do this as another post-installation
> task and avoid all use of threading.
As I've tried to explain in the mail commenting the patch set, doing
this as a post-installation task might lead to situation where something
bad happens before we save system time to RTC and user would end up with
an unusable system, that has e.g. partitions from the future. I think
saving system time to RTC has to be done as the first thing after the
"point of no return" (clicking Begin Installation). Another "UTC guess"
should probably be run there, because user may remove bootable NTFS
partitions in partitioning.

On the other hand, restoring (with the "UTC guess") has to be done
before we let user modify time in the DateTime spoke. Or we could drop
this part and let user correct the time manually if it was stored as
localtime and loaded as UTC. Then save it as localtime or UTC
accordingly to the existing partitions at the begining of the
installation. That would not need any new threads.

-- 
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic



More information about the anaconda-patches mailing list