linux-kernel - Re: CONFIG_RTC_HCTOSYS lost on x86 with ALWAYS_USE_PERSISTENT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <517989E7.3040101@linaro.org>
Date:	Thu, 25 Apr 2013 12:54:15 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Kay Sievers <kay@...y.org>
CC:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Alexander Holler <holler@...oftware.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Feng Tang <feng.tang@...el.com>
Subject: Re: CONFIG_RTC_HCTOSYS lost on x86 with ALWAYS_USE_PERSISTENT_CLOCK
 changes?

On 04/25/2013 12:45 PM, Kay Sievers wrote:
> On Thu, Apr 25, 2013 at 8:33 PM, Jason Gunthorpe
> <jgunthorpe@...idianresearch.com> wrote:
>> So, my conclusion is nobody with a RTC looking for space savings, will
>> disable CONFIG_RTC, which means we can safely rely on
>> CONFIG_RTC_SYSTOHC to do this work. To that end, I would encourage
>> everyone who sets CONFIG_GENERIC_CMOS_UPDATE to also set
>> CONFIG_RTC_SYSTOHC - that will let update_persistent_clock to be
>> ripped out over time without impacting users.
> John's original patch forcefully disabled CONFIG_RTC_SYSTOHC on x86,
> which is quite the opposite of what you recommend here. :)
>
> Could you guys both sort that out and give an idea what the
> recommended setup should look like today, ignoring all space saving
> and possible hctosys API changes caused by this. Should
> CONFIG_RTC_SYSTOHC be enabled or not?

Its fine if its enabled. We have logic in the kernel to do the right 
thing when we're on a system that has the persistent clock and also has 
SYSTOHC enabled.

My patch disabled SYSTOHC just to simplify some of the logic at build 
time, and in my mind, simplify the config choices.
But as much as I dislike needless config choices, I realize config churn 
isn't great either.

So I do think as we eventually consolidate the RTC and persistent_clock 
code, using SYSTOHC in the end is probably a good way to go (although we 
may drop the config and just always enable that logic).

That said, I suspect we need RTC equivalents to the xen/kvm/vrtc logic 
in the x86 persistent_clock code before we'll be able to tear out the 
persistent_clock code (I think just cmos and efi have RTC drivers).

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/