Zhaoming Luo, le mar. 19 nov. 2024 16:54:38 +0800, a ecrit: > On 11/17/24 9:04 PM, Sergey Bugaev wrote: > I don't think I need to do anything before exit. However, maybe I need to > ensure the rtc operations is thread-safe; I haven't done it.
Ah, yes. Since it's not a performance-critical service, you can as well use ports_manage_port_operations_one_thread instead, and get done with it :) > I will do some experiments to see whether two threads setting rtc causes > data race It will since cmos access requires two outb calls, but it'll be very hard to reproduce. > > > + The following flags have to be released exactly in this order, > > > + otherwise the DS12887 (popular MC146818A clone with integrated > > > + battery and quartz) will not reset the oscillator and will not > > > + update precisely 500 ms later. You won't find this mentioned in > > > + the Dallas Semiconductor data sheets, but who believes data > > > + sheets anyway ... -- Markus Kuhn */ > > > + cmos_write(11, save_control); > > > + cmos_write(10, save_freq_select); > > > > Can these writes somehow fail, and if so, can you detect it and report > > the error? (I've no idea.) > I think the only way to check is reading rtc between `cmos_write(9, > tm.tm_year);` and `cmos_write(11, save_control);`; then compare the values > we just read with the values for setting. I don't think it is useful to do this. Nowadays RTC is not even a separate chip, we won't have any issue. Samuel
