[GIT PULL] Device properties framework update for v4.18-rc1

[GIT PULL] Device properties framework update for v4.18-rc1

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 dp-4.18-rc1

with top-most commit 63dcc7090137a893322432e156d66be3ce104615

 device property: Get rid of union aliasing

on top of commit 67b8d5c7081221efa252e111cd52532ec6d4266f

 Linux 4.17-rc5

to receive a device properties framework update for 4.18-rc1.

This modifies the device properties framework to remove union
aliasing from it (Andy Shevchenko).

Thanks!


---------------

Andy Shevchenko (1):
      device property: Get rid of union aliasing

---------------

 drivers/base/property.c                 | 104 ++++++++++++++++++++++++++------
 drivers/firmware/efi/apple-properties.c |   8 ++-
 include/linux/property.h                |  52 ++++++++--------
 3 files changed, 117 insertions(+), 47 deletions(-)

Re: [GIT PULL] Device properties framework update for v4.18-rc1

[Linus Torvalds]

On Mon, Jun 4, 2018 at 4:31 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
>  device property: Get rid of union aliasing

Honestly, this looks questionable to me.

I'm not talking about the changes themselves - I can live with them.
But the _rationale_ is pure and utter garbage, and dangerously so.

The fact is, using a union to do type punning is the traditional AND
STANDARD way to do type punning in gcc. In fact, it is the
*documented* way to do it for gcc, when you are a f*cking moron and
use "-fstrict-aliasing" and need to undo the braindamage that that
piece of garbage C standard imposes.

So the commit message that talks about how horrible union aliasing is
is pushing a story that is simply wrong. Using the standard to push it
- the same standard that came up with the completely mis-guided
aliasing rules - is not a valid argument.

Andy, what is the background for trying to push this idiocy? Don't
tell me "the C standard is unclear". The C standard is _clearly_ bogus
shit (see above on strict aliasing rules), and when it is bogus
garbage, it needs to be explicitly ignored, and it needs per-compiler
workarounds for braindamage. The exact same situation is true when
there is some lack of clarity.

This is why we use -fwrapv, -fno-strict-aliasing etc. The standard
simply is not *important*, when it is in direct conflict with reality
and reliable code generation.

The *fact* is that gcc documents type punning through unions as the
"right way". You may disagree with that, but putting some theoretical
standards language over the *explicit* and long-time documentation of
the main compiler we use is pure and utter bullshit.

I've said this before, and I'll say it again: a standards paper is
just so much toilet paper when it conflicts with reality. It has
absolutely _zero_ relevance. In fact, I'll take real toilet paper over
standards any day, because at least that way I won't have splinters
and ink up my arse.

So I want to see actual real arguments, not "the standard is unclear".
When documented gcc behavior says one thing, and the standard might be
unclear, we really don't care one whit about the lack of clarity in
some standard.

So what's the _real_ reason for avoiding union aliasing?

There are competent people on standards bodies. But they aren't
_always_ competent, and the translation of intent to English isn't
always perfect either. So standards are not some kind of holy book
that has to be revered. Standards too need to be questioned.

                 Linus

Re: [GIT PULL] Device properties framework update for v4.18-rc1

[Linus Torvalds]

On Tue, Jun 5, 2018 at 10:30 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Honestly, this looks questionable to me.
>
> I'm not talking about the changes themselves - I can live with them.
> But the _rationale_ is pure and utter garbage, and dangerously so.

Side note: I've merged it, and it's going through my build tests, so
it's really not that I hate the code.

But I really find that kind of one-sided rationale that ignores
reality unacceptable.

And I find it dangerous, because it *sounds* so "obviously correct" to
people who don't know any better. If you don't know that gcc
explicitly says that you should use unions to do type punning to avoid
aliasing issues, you might believe that union type punning is a bad
thing from that commit message.

So it's dangerously misleading, because lots of people have a
dangerous reverence for paper over reality.

In programming, "Appeal to Standards" should be considered a potential
logical fallacy. Standards have their place, but they definitely have
their caveats too.

                    Linus

Re: [GIT PULL] Device properties framework update for v4.18-rc1

[Rafael J. Wysocki]

On Tue, Jun 5, 2018 at 7:39 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, Jun 5, 2018 at 10:30 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> Honestly, this looks questionable to me.
>>
>> I'm not talking about the changes themselves - I can live with them.
>> But the _rationale_ is pure and utter garbage, and dangerously so.
>
> Side note: I've merged it, and it's going through my build tests, so
> it's really not that I hate the code.
>
> But I really find that kind of one-sided rationale that ignores
> reality unacceptable.
>
> And I find it dangerous, because it *sounds* so "obviously correct" to
> people who don't know any better. If you don't know that gcc
> explicitly says that you should use unions to do type punning to avoid
> aliasing issues, you might believe that union type punning is a bad
> thing from that commit message.
>
> So it's dangerously misleading, because lots of people have a
> dangerous reverence for paper over reality.
>
> In programming, "Appeal to Standards" should be considered a potential
> logical fallacy. Standards have their place, but they definitely have
> their caveats too.

Well, AFAICS the point was that the union aliasing was not
particularly useful in this case and it clearly was avoidable.  The
changelog could do a better job at explaining that, though, sorry
about that.

And thanks for merging it in spite of your concerns!

Rafael

Re: [GIT PULL] Device properties framework update for v4.18-rc1

[Andy Shevchenko]

On Tue, 2018-06-05 at 10:39 -0700, Linus Torvalds wrote:
> On Tue, Jun 5, 2018 at 10:30 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > 
> > Honestly, this looks questionable to me.
> > 
> > I'm not talking about the changes themselves - I can live with them.
> > But the _rationale_ is pure and utter garbage, and dangerously so.
> 
> Side note: I've merged it, and it's going through my build tests, so
> it's really not that I hate the code.

Thanks for merging.

> 
> But I really find that kind of one-sided rationale that ignores
> reality unacceptable.

Yeah, there were few reasons why I decide to make that patch (OK, it
seems I staked on not the best reason).

Like Rafael said there is no need to use it here and code initially was
without union aliasing be in place.

> And I find it dangerous, because it *sounds* so "obviously correct" to
> people who don't know any better. If you don't know that gcc
> explicitly says that you should use unions to do type punning to avoid
> aliasing issues, you might believe that union type punning is a bad
> thing from that commit message.
> 
> So it's dangerously misleading, because lots of people have a
> dangerous reverence for paper over reality.

I agree with you, because type punning via unions feels natural and
that's why I even didn't notice when made a refactoring there several
releases before.

> In programming, "Appeal to Standards" should be considered a potential
> logical fallacy. Standards have their place, but they definitely have
> their caveats too.

Yes, even outside of programming.

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy