Dave,
On Fri, Sep 03 2021 at 08:35, Dave Chinner wrote:
> On Thu, Sep 02, 2021 at 10:43:11AM -0700, Darrick J. Wong wrote:
> The part I dislike most about it is that we have to modify a header
> file that triggers full kernel rebuilds. Managing patch stacks and
> branches where one of them modifies such a header file means quick,
> XFS subsystem only kernel rebuilds are a rare thing...
If you don't care about ordering, you can avoid touching the global
header completely. The dynamic state ranges in PREPARE and ONLINE
provide exactly what you want. It's documented.
> That said, I'm all for a better interface to the CPU hotplug
> notifications. THe current interface is ... esoteric and to
What's so esoteric about:
state = cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "xfs:prepare", func1, func2);
state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "xfs:online", func3, func4);
Only if you care about callback ordering vs. other subsystems, then adding
the state in the global header is required. It's neither the end of the
world, nor is it rocket science and requires expert knowledge to do so.
> understand how to use it effectively requires becoming a CPU hotplug
> expert.
https://www.kernel.org/doc/html/latest/core-api/cpu_hotplug.html
If there is something missing in that documentation which makes you
think you need to become a CPU hotplug expert, please let me know. I'm
happy to expand that document.
> There's something to be said for the simplicity of the old
> register_cpu_notifier() interface we used to have...
There is a lot to be said about it. The simplicity of it made people do
the most hillarious things to deal with:
- Ordering issues including build order dependencies
- Asymetry between bringup and teardown
- The inability to test state transitions
- ....
Back then when we converted the notifier mess 35 of ~140 hotplug
notifiers (i.e. ~25%) contained bugs of all sorts. Quite some of them
were caused by the well understood simplicity of the hotplug notifier
mechanics. I'm surely not missing any of that.
Thanks,
tglx
