On Mon, 2024-10-14 at 13:12 -0700, Jakub Kicinski wrote: > On Mon, 14 Oct 2024 08:25:35 +0100 David Woodhouse wrote: > > On Wed, 2024-10-09 at 17:32 -0700, Jakub Kicinski wrote: > > > On Sun, 06 Oct 2024 08:17:58 +0100 David Woodhouse wrote: > > > > +config PTP_1588_CLOCK_VMCLOCK > > > > + tristate "Virtual machine PTP clock" > > > > + depends on X86_TSC || ARM_ARCH_TIMER > > > > + depends on PTP_1588_CLOCK && ACPI && ARCH_SUPPORTS_INT128 > > > > + default y > > > > > > Why default to enabled? Linus will not be happy.. > > > > Want an incremental patch to change that? > > Yes please and thank you! We gotta straighten it out before > the merge window. Hm, as I (finally) come to do that, I realise that many of the others defined in drivers/ptp/Kconfig are also 'default y'. Which is only really 'default PTP_1588_CLOCK' in practice since they all depend on that. Most importantly, PTP_1588_CLOCK_KVM is 'default y'. And that one is fundamentally broken (at least in the presence of live migration if guests care about their clock suddenly being wrong) which is why it's being superseded by the new VMCLOCK thing. We absolutely don't want to leave the _KVM one enabled by default and not its _VMCLOCK replacement. Please advise... I suspect the best answer is to leave it as it is?
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
