[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH 0/1] Add rtc translator, RTC CMOS driver and hwclock
From: |
Zhaoming Luo |
Subject: |
[PATCH 0/1] Add rtc translator, RTC CMOS driver and hwclock |
Date: |
Thu, 5 Dec 2024 20:38:37 +0800 |
Because the hurd patch (rtc translator and RTC CMOS driver) is a bit
related to the patch for util-linux (support hwclock in Hurd), I decided
to send them together.
We will see the following functions after applying the patch:
```
Functions:
-r, --show display the RTC time
--get display drift corrected RTC time
--set set the RTC according to --date
-s, --hctosys set the system time from the RTC
-w, --systohc set the RTC from the system time
--systz send timescale configurations to the kernel
-a, --adjust adjust the RTC to account for systematic drift
--predict predict the drifted RTC time according to
--date
```
I have tested those functions, they works perfectly expect --systz. The
hwclock said the issue is `settimeofday() failed: Function not
implemented`. However, settimeofday is obsolescent[0] so I think we can
ignore it.
You will see in rtc-cmos_pioctl-ops.c RTC_UIE_ON and RTC_UIE_OFF just
return EOPNOTSUPP. Samuel mentioned a proper implementation is quite
involved; it means registering to gnumach ... etc. A solution would be
using the busy-wait method used by hwclock. However, hwclock itself will
select the busy-wait method (hwclock has a built-in one) automatically
if RTC_UIE_ON ioctl fails. Therefore, I think before there are some other
softwares want to use RTC_UIE_ON, we can just use placeholders.
BTW I'm quite interested in that proper implementation :).
About the adding of O_WRONLY in hwclock-rtc.c in the util-linux patch.
It's quite weird that hurd (in qemu) cannot set time without O_WRONLY
but linux (on my linux laptop) can.
[0]: https://www.mail-archive.com/info-gnu@gnu.org/msg02694.html
--
2.45.2
- [PATCH 0/1] Add rtc translator, RTC CMOS driver and hwclock,
Zhaoming Luo <=