On Sun, 28 Oct 2018, Geert Uytterhoeven wrote:
The example I gave was GENERIC_CLOCKEVENTS on m68, which is
supported on most but not all machines there.
That suggests that the removal of just those machines would suffice
(as opposed to the removal of the entire arch).
Also, Documentation/features/time/clockevents/arch-support.txt says,
| m68k: | ok |
These two observations make me wonder whether the clockevents feature
is related to the discussion quoted above (?)
GENERIC_CLOCKEVENTS is selected only for a few Coldfire CPU types.
Certain arm and m68k platforms select ARCH_USES_GETTIMEOFFSET (hence these
architectures have "TODO" in features/time/modern-timekeeping).
Moreover, it seems that we need both features (!ARCH_USES_GETTIMEOFFSET &&
GENERIC_CLOCKEVENTS) in order to get the benefit of simplification...
Perhaps the most overdue features are the following. At least 50% of
architectures have already implemented these features (or else cannot
implement them).
$ grep -cw TODO Documentation/features/*/*/arch-support.txt |sort -t: -k2n |head -n 9
Documentation/features/time/clockevents/arch-support.txt:1
Documentation/features/time/modern-timekeeping/arch-support.txt:2
Documentation/features/vm/numa-memblock/arch-support.txt:2
Documentation/features/vm/THP/arch-support.txt:5
Documentation/features/sched/numa-balancing/arch-support.txt:6
Documentation/features/core/tracehook/arch-support.txt:7
Documentation/features/core/generic-idle-thread/arch-support.txt:8
Documentation/features/locking/lockdep/arch-support.txt:8
Documentation/features/debug/kgdb/arch-support.txt:12
Of those, m68k has a "TODO" against the following 5 features.
time/modern-timekeeping
core/tracehook
core/generic-idle-thread
locking/lockdep
debug/kgdb
The question is, which of those features, if implemented, would contribute
the most towards the goal (that is, to keep things simpler)?
That's a very good question!
I think it would be helpful if Documentation/features/... would state what
kind of benefit warranted the TODO.
E.g. a win-win simplification arises from replacing arch code with generic
code. Another kind of simplification arises from removing special cases
from core code.
The !ARCH_USES_GETTIMEOFFSET && GENERIC_CLOCKEVENTS example seems to offer
both kinds of benefit.
E.g. kgdb is not a must-have, and lockdep matters much less if !SMP (and
I don't have RAM for storing all data it needs anyway).
Perhaps we should ask, "which features, if implemented, would actually
complicate things, taking us further from the goal?"
In those cases, "TODO" seems to be bad advice. Perhaps "optional" would be
better.
--
