Almost all machines use GENERIC_CLOCKEVENTS, so it feels wrong to require each one to select that symbol manually. Instead, enable it whenever CONFIG_LEGACY_TIMER_TICK is disabled as a simplification. It should be possible to select both GENERIC_CLOCKEVENTS and LEGACY_TIMER_TICK from an architecture now and decide at runtime between the two. For the clockevents arch-support.txt file, this means that additional architectures are marked as TODO when they have at least one machine that still uses LEGACY_TIMER_TICK, rather than being marked 'ok' when at least one machine has been converted. This means that both m68k and arm (for riscpc) revert to TODO. At this point, we could just always enable CONFIG_GENERIC_CLOCKEVENTS rather than leaving it off when not needed. I built an m68k defconfig kernel (using gcc-10.1.0) and found that this would add around 5.5KB in kernel image size: text data bss dec hex filename 3861936 1092236 196656 5150828 4e986c obj-m68k/vmlinux-no-clockevent 3866201 1093832 196184 5156217 4ead79 obj-m68k/vmlinux-clockevent On Arm (MACH_RPC), that difference appears to be twice as large, around 11KB on top of an 6MB vmlinux.
Showing the changes to kernel (1 of 25 files). Show all
Unified · Split
| @@ -28,7 +28,7 @@ config GENERIC_TIME_VSYSCALL · 27 unmodified lines | |||
| 28 | 28 | ||
| 29 | # The generic clock events infrastructure | 29 | # The generic clock events infrastructure |
| 30 | config GENERIC_CLOCKEVENTS | 30 | config GENERIC_CLOCKEVENTS |
| 31 | bool | 31 | def_bool !LEGACY_TIMER_TICK |
| 32 | 32 | ||
| 33 | # Architecture can handle broadcast in a driver-agnostic way | 33 | # Architecture can handle broadcast in a driver-agnostic way |
| 34 | config ARCH_HAS_TICK_BROADCAST | 34 | config ARCH_HAS_TICK_BROADCAST |