Łukasz Pankowski wrote: > The question here is whether otimed (or fsodeviced or whatever) ensures > /dev/rtc matches system clock when > org.freesmartphone.Time.Alarm.SetAlarm is called (or somewhere else).
otimed is responsible for setting the system clock. And that has no access as long as fsodeviced locks access. (BTW, I verified that I can "cat /dev/rtc0" after killing fsodeviced). Just try a simple hwclock -f /dev/rtc0 it won't work. Nothing can set the system time now. So it's no surprise that time doesn't survive reboots. > When I was looking at the issue in March 2009 it seemed not to be doing > that, so I made atd-over-fso ensures that (i.e. did not removed the code > inherited from atd which sets rtc from system time before setting > alarm). (I have not look into this issue since that time). /me shrugs. I just had a brief look at atd-over-fso code and it seems to have been last modified 5 years ago. Someone might want to look at it anyway and upstream those patches that are applied to it... spaetz
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Shr-devel mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-devel
