Hi Marc,

On Wed, May 26, 2021 at 10:32 AM Marc Zyngier [off-list ref] wrote:

On Wed, 26 May 2021 09:18:27 +0100,
Geert Uytterhoeven [off-list ref] wrote:

quoted

On Wed, May 26, 2021 at 10:01 AM Marc Zyngier [off-list ref] wrote:

quoted

On Wed, 26 May 2021 08:52:42 +0100,
Geert Uytterhoeven [off-list ref] wrote:

quoted

On Tue, May 11, 2021 at 11:13 AM Marc Zyngier [off-list ref] wrote:

quoted

On 2021-05-11 10:07, Geert Uytterhoeven wrote:

quoted

On Tue, Mar 30, 2021 at 4:56 PM Marc Zyngier [off-list ref] wrote:

quoted

From: Jianyong Wu <redacted>

quoted

--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig

@@ -108,7 +108,7 @@ config PTP_1588_CLOCK_PCH
 config PTP_1588_CLOCK_KVM
        tristate "KVM virtual PTP clock"
        depends on PTP_1588_CLOCK
-       depends on KVM_GUEST && X86
+       depends on (KVM_GUEST && X86) || (HAVE_ARM_SMCCC_DISCOVERY &&

ARM_ARCH_TIMER)

Why does this not depend on KVM_GUEST on ARM?
I.e. shouldn't the dependency be:

    KVM_GUEST && (X86 || (HAVE_ARM_SMCCC_DISCOVERY && ARM_ARCH_TIMER))

?

arm/arm64 do not select KVM_GUEST. Any kernel can be used for a guest,
and KVM/arm64 doesn't know about this configuration symbol.

OK.

Does PTP_1588_CLOCK_KVM need to default to yes?
Perhaps only on X86, to maintain the status quo?

I think I don't really understand the problem you are trying to
solve. Is it that 'make oldconfig' now asks you about this new driver?
Why is that an issue?

My first "problem" was that it asked about this new driver on
arm/arm64, while I assumed there were some missing dependencies
(configuring a kernel should not ask useless questions).  That turned
out to be a wrong assumption, so there is no such problem here.

The second problem is "default y": code that is not critical should
not be enabled by default.  Hence my last question.

I think consistency between architectures is important. Certainly,
distributions depend on that, and we otherwise end-up with distro
kernels missing functionalities.

The notion of "critical" is also pretty relative. defconfig contains a

I'm not talking about defconfig, but about "default y" in defconfig.

gazillion of things that are not critical to most people, for example,
and yet misses a bunch of things that are needed to boot on some of my
systems.

Perhaps those should be added, so those systems can be tested using
defconfig?  At least for arm64, I think that's aligned with the
arm64 defconfig policy.

That's just to say that I find it difficult to make that choice from
the PoV of a kernel hacker. I'm personally more inclined to leave
things enabled and let people *disable* things if they want to reduce
the footprint of their kernel.

The standard question to respond to w.r.t. "default y" is: "Why is
your feature so special that it needs to be enabled by default?",
which implies "default y" is the exception, not the rule.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds