On 7 January 2017 at 23:06, Sami Kerola <kerolasa@xxxxxx> wrote: > On Sat, 7 Jan 2017, J William Piggott wrote: >> commit 509ac719dbe1bcc4a761f694497493525da39e25 >> Author: Sami Kerola <kerolasa@xxxxxx> >> Date: Sun Jul 17 09:09:33 2016 +0100 >> >> docs: add instructions how to avoid alpha epoc Y2020 bug >> >> Recommend setting epoch using command line to for Alpha to avoid >> autodetection that is doomed to afail after 2020. >> >> Reference: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/alpha/kernel/rtc.c?id=85d0b3a573d8b711ee0c96199ac24a0f3283ed68 >> Signed-off-by: Sami Kerola <kerolasa@xxxxxx> >> >> diff --git a/sys-utils/hwclock-cmos.c b/sys-utils/hwclock-cmos.c >> index 9d9a42a..cf26064 100644 >> --- a/sys-utils/hwclock-cmos.c >> +++ b/sys-utils/hwclock-cmos.c >> @@ -203,15 +203,16 @@ void set_cmos_epoch(const struct hwclock_control *ctl) >> #endif >> >> /* >> - * The kernel source today says: read the year. >> + * The automatic epoc determination in kernel >> + * linux/arch/alpha/kernel/rtc.c >> * >> * If it is in 0-19 then the epoch is 2000. >> * If it is in 20-47 then the epoch is 1980. >> * If it is in 48-69 then the epoch is 1952. >> * If it is in 70-99 then the epoch is 1928. >> * >> - * Otherwise the epoch is 1900. >> - * TODO: Clearly, this must be changed before 2019. >> + * Alpha users should explicitly define epoc using rtc kernel module >> + * option rtc epoc=<year> >> */ >> /* >> * See whether we are dealing with SRM or MILO, as they have >> diff --git a/sys-utils/hwclock.8.in b/sys-utils/hwclock.8.in >> index 9534c19..de68e43 100644 >> --- a/sys-utils/hwclock.8.in >> +++ b/sys-utils/hwclock.8.in >> @@ -466,6 +466,14 @@ For example, on a Digital Unix machine: >> .IP "" 4 >> .B hwclock\ \-\-setepoch\ \-\-epoch=1952 >> .RE >> +.IP >> +Beginning January 1, 2020 automatic epoc determination in kernel for systems >> +using 1900 will fail. In these cases it is recommended to specify epoc >> +explicitly with kernel module option. >> +.RS >> +.IP "" 4 >> +.B options rtc epoch=1900 >> +.RE >> . >> .TP >> .B \-\-funky\-toy >> >> >> > >> > I don't like this one because: >> > >> > Despite Richard's "doomed to fail" comment, I don't think util-linux >> > should document that as a fact. The heuristics could be updated. If the >> > kernel is still supporting DEC in 2019 it seems like they should >> > update them. It would be more work to remove the code than to adjust >> > the numbers. >> > >> > Also the patch has some errors: >> > >> > * The possible failure applies to more than 'systems using 1900'. >> > >> > * The Alpha rtc driver cannot be built as a module; I believe >> > epoch={year} is a kernel command line argument only. >> > >> > * The heuristics in drivers/char/rtc.c are slightly different than >> > what the patch references in linux/arch/alpha/kernel/rtc.c. I don't >> > know which one wins. They both differ from how they are described in >> > the hwclock-cmos.c comments, from which this patch deletes the 1900 >> > possibility. >> > >> > The Alpha auto epoch detect has nothing to do with hwclock --setepoch >> > --epoch {year}. That is all done via rtc and can only set it manually. >> > Auto detecting the epoch only affects using --directisa on Alpha >> > machines. Direct access requires hwclock to handle the epoch offset >> > internally, because we're bypassing the kernel. So hwclock-cmos.c has >> > to figure out what to use. It tries heuristics and, ironically, it >> > tries to use the kernel's auto detect via the rtc driver. Why use >> > direct access if you have a working rtc interface! >> > >> > It is undocumented, but when using --directisa on alpha --epoch {year} >> > can be used to bypass auto detect. So --epoch {year} would be used for >> > all functions. The man-page says it can only be used with --setepoch. >> > I have no way to test this, so until now I have not documented it. >> > > > I left the change as-is for now, making the branch in it's current state > not to be ready. How about if I read carefully what you said above, > rethink what I thought earlier, and reply later. This change is dropped. What comes to other comments nice to hear 'doomed to fail' is not quite as bad situation as it was made to sound. Maybe it would be appropriate to deal alpha 2020 issue separately, with kernel upstream alpha maintainers. Right now my only recommendation is to clear out the situation this year (2017). After all 2020 is just round corner. We shall see whether clearning out means code and docs changes to kernel, hwclock, or both. -- Sami Kerola http://www.iki.fi/kerolasa/ -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
