Messages in this thread | | | Subject | Re: [RFC][PATCH 0/5] Introduce checks for preemptable code for this_cpu_read/write() | From | Steven Rostedt <> | Date | Wed, 21 Sep 2011 12:12:01 -0400 |
| |
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
| |