Conflict between 1-indexed kernel struct rtc_time and 0-indexed userspace struct tm
Hello,
The difference seems undocumented and ignored by userspace. At https://
github.com/util-linux/util-linux/issues/3707 , we discussed the mismatch. My kernel module's assertion that a rtc_time64_to_tm(rtc_tm_to_time64(tm), &tm_check) will result in a bit-identical struct failed at tm_yday.
Userspace https://man7.org/linux/man-pages/man3/tm.3type.html documents a 0-
indexed int tm_yday; /* Day of the year [0, 365] (Jan/01 = 0) */
The kernel struct rtc_time is uncommented, but https://github.com/torvalds/
linux/blob/b6add54ba61890450fa54fd9327d10fdfd653439/drivers/rtc/lib.c#L136 intentionally adds 1 to make it 1-indexed, and this appears to have been consistent through git history. rtc-asm9260.c and rtc-lpc24xx.c read from tm_yday before writing to hardware, but it tm_yday may have been corrected by an overwrite by other parts of the rtc core. My kernel module validates tm_yday but doesn't use it, whereas it may be unknown whether other modules are expecting a 1-indexed or 0-indexed value.
I was about to suggest that userspace perform tm_year++ before the ioctl, but then https://github.com/systemd/systemd/issues/
Quoted 2 lines · 38715#issuecomment-3221685983 said:
At least, rtc(4) states about struct
rtc_timeasQuoted 1 line
The fields in this structure have the same meaning and ranges as for the tm
structure described in gmtime(3).
Quoted 1 line
I guess this is a kernel driver or firmware issue if it does not work.
What should be done to make the 0-indexing/1-indexing of tm_yday consistent between kernelspace and userspace?
Sincerely,
daniel . z . tg