Re: [RFC][PATCH 0/5] arch: atomic rework

From: Torvald Riegel
Date: Fri Feb 14 2014 - 14:19:58 EST


On Fri, 2014-02-14 at 10:50 +0100, Peter Zijlstra wrote:
> On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote:
> > That depends on what your goal is.

First, I don't know why you quoted that, but without the context,
quoting it doesn't make sense. Let me repeat the point. The standard
is the rule set for the compiler. Period. The compiler does not just
serve the semantics that you might have in your head. It does have to
do something meaningful for all of its users. Thus, the goal for the
compiler is to properly compile programs in the language as specified.

If there is a deficiency in the standard (bug or missing feature) -- and
thus the specification, we need to have a patch for the standard that
fixes this deficiency. If you think that this is the case, that's where
you fix it.

If your goal is to do wishful thinking, imagine some kind of semantics
in your head, and then assume that magically, implementations will do
just that, then that's bound to fail.

> A compiler that we don't need to fight in order to generate sane code
> would be nice. But as Linus said; we can continue to ignore you lot and
> go on as we've done.

I don't see why it's so hard to understand that you need to specify
semantics, and the place (or at least the base) for that is the
standard. Aren't you guys the ones replying "send a patch"? :)

This isn't any different. If you're uncomfortable working with the
standard, then say so, and reach out to people that aren't.

You can surely ignore the specification of the language(s) that you are
depending on. But that won't help you. If you want a change, get
involved. (Oh, and claiming that the other side doesn't get it doesn't
count as getting involved.)

There's no fight between people here. It's just a technical problem
that we have to solve in the right way.

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