於 五，2013-12-20 於 17:51 -0800，H. Peter Anvin 提到： > On 12/20/2013 05:24 PM, joeyli wrote: > > 於 五，2013-12-20 於 13:04 -0800，H. Peter Anvin 提到： > >> > >> Actually, it doesn't have to reprogram the clock ... it just needs to > >> know if another OS has already done so. All Linux needs to do is to be > >> able to derive UTC from whatever the RTC is set to and to be able to > >> keep it consistent. > >> > > > > It's dependent on a right boot initial priority of distribution. > > -ENOPARSE > > > Here have a discussion of adjusting system clock by TZ (from ACPI or > > UEFI): > > Discussion on BIOS/CMOS/UEFI clock in local time > > http://www.spinics.net/lists/util-linux-ng/msg07639.html > > > > and, > > from Ted Ts'o in the mail thread > > https://lkml.org/lkml/2008/1/8/195 > > > > If kernel use the TZ field from ACPI TAD or EFI to adjust system > > clock when booting, then it can avoid buggy distributions adjust > > system clock AFTER e2fsck is run. > > > > Using ACPI TAD should after DSDT parsing in subsystem initial stage, > > so I choice EFI time services before we can move DSDT parser to > > start_kernel(). > > > > Yes, of course. That is irrelevant to needing to reprogram the clock, > though. > > My argument is very simple: if we have to rely on EFI, we can get the > offset in the boot stub before ExitBootServices(), and then simply never > change it. That way we still pick up if another operating system has > changed it, and it will still reflect the proper UTC time. > > -hpa >
OK, I will add this part to next version for the UEFI system doesn't have ACPI TAD. Thanks for your suggestion! Joey Lee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
