Message-ID: <alpine.LFD.2.02.1301312302290.11905@ionos>
Date:	Thu, 31 Jan 2013 23:44:09 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	Arjan van de Veen <arjan@...radead.org>,
	Paul Turner <pjt@...gle.com>,
	Richard Weinberger <rw@...utronix.de>,
	Magnus Damm <magnus.damm@...il.com>
Subject: Re: [patch 00/40] CPU hotplug rework - episode I

On Fri, 1 Feb 2013, Linus Torvalds wrote:
> On Fri, Feb 1, 2013 at 8:48 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
> I think we want as many people as possible cc'd on this. You may think
> it's an obvious improvement, but maybe it's just because you now
> understand the code because you wrote it yourself, not because it's
> *actually* better.

Fair enough.
 
> Having some explicitly documented states may be nice, but do we need
> eleven of them? And do we want to expose them? At least not for the
> f*cking notifiers, I hope. Notifiers are a disgrace, and almost all of
> them are a major design mistake. They all have locking problems, the
> introduce internal arbitrary API's that are hard to fix later (because
> you have random people who decided to hook into them, which is the
> whole *point* of those notifier chains).

That's the whole point of this. The notifier chains are random places
which allow people to add crap at will. And they did. Just grep for
any of the gazillions hotplug notifier implementations. Though some of
them you might not be able to find because they are burried under a
subsystem macro magic.
 
> Since the patches themselves weren't cc'd, I don't know if you

I screwed up the 0/40 cover header and therefor quilt decided to
exclude you from that 40 patches mail bomb :(

Poke me if you want a private copy

> actually made each state transition do those insane notifiers or not,
> but I seriously hope you didn't. With that many states, hopefully the
> idea is that you don't have any notifiers at all, and you just then
> call the people associated with a particular state directly. Yes? No?

The current lot of patches are converting parts of the documented and
undocumented notifier callbacks into an array of callbacks which
documents the ordering. Some of the patches aggregate multiple
notifiers to a single one which ensures the ordering of the subsystem
specific ones, but at the moment I concentrated to provide a path from
a wild notifier scheme to a documented list of callbacks.
 
> Because if this adds tons of new notifiers, I'm going to say that we

No. It does not add any new notifiers. It simply converts notifier
randomness, i.e. your personal choice of CPU_* action flavor to an
ordered list.

> need about a hundred people signing off on the patches.  Part of your
> explanation made me think you got rid of the notifiers, but then it

I wish I could have got rid of the notifiers. But do you have a way to
do that w/o breaking the world and some more ? The only way to do that
would be reimplementing it from scratch. Sure we can do that, and hell
I know how, but we cannot do that in the current workflow. That would
require a switch back to the 2.odd/even scheme and we all know how
well this works out.

> became clear that you just renamed them as "state callbacks". If

It's not about renaming. It's about making the ordering constraints
clear. It's about documenting the existing horror in a way, that one
can understand the hotplug process w/o hallucinogenic drugs.

> that's some generic exposed interface, I'll NAK it. No way in hell do
> we want to expose eleven states with some random generic "SMP state
> callback interface". F*ck no.

Just face it. The current hotplug maze has 100+ states which are
completely undocumented. They are asymetric vs. startup and
teardown. They just exists and work somehow aside of the occasional
hard to decode hickup.

Do you really want to preserve that state by all means [F*ck no]?

Thanks,

	tglx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists