Re: [RFC][PATCH 0/5] Introduce checks for preemptable code for this_cpu_read/write()

Steven Rostedt
2011-09-21T16:12:06Z

On Wed, 2011-09-21 at 10:59 -0500, Christoph Lameter wrote:
> On Wed, 21 Sep 2011, Steven Rostedt wrote:
>
> > The problem I have with this, is that this does not help at all. We are
> > back to the word "this_cpu" when you really do mean "any_cpu". We
>
> We mean the current cpu while the instruction is executing.

Yes, again that is a implementation detail not a design one. The
"current cpu" is nothing more than an optimization. The code is still
written in a way that it would work if you wrote it to another CPU as
long as the operation itself was atomic.

>
> > Again, lets just bite the bullet and rename them to something that is
> > understandable for everyone. This would make all of us happy.
> >
> > I'm not against your code, I'm against the naming convention you decided
> > to use. It makes it confusing to something that is complex and complex
> > code needs to try to be a simple as possible.
>
> I am certainly open to new ways of structuring the stuff and for any
> improvement possible. This whole scheme was developed in long discussions
> over many years. My initial proposal was to use cpu_inc/dec etc. I did
> what was possible in the context of the various opinions that people had
> on these matters when the implementations were discussed. The "you" does
> not apply. It is either "us" or "them" (if you want to distance yourself
> from this).

Who is this "them"? Currently the only ones that matter to me is the
mainline kernel developers. They are the ones that have to live with
this nonsense. If the "them" includes other mainline kernel developers
that are not on the Cc, please add them. Otherwise, I really don't give
a flying fart about the "them".

This is all about a naming convention, not the implementation. The
current naming convention is extremely confusing. As the mistakes that
have been shown through out the kernel. Worse yet, you removed the debug
features that have been there forever and don't even care. Just calling
the users that break the code irresponsible is not going to get you
anywhere.

We have already talked about bringing this up at Kernel Summit. Too bad
you wont be there. Make sure one of the "them" is there to defend this
silly naming convention, otherwise I will push to get all the main
kernel developers accepting a renaming of this internal API. And
immediately after the conference I will start sending patches that will
be accepted.

-- Steve