lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTilmqWhHFO5zpfe5g53adUd18nIDli2tJt54k3rg@mail.gmail.com>
Date:	Tue, 13 Jul 2010 17:15:02 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Peter Palfrader <peter@...frader.org>,
	Avi Kivity <avi@...hat.com>, Greg KH <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, stable@...nel.org,
	stable-review@...nel.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Glauber Costa <glommer@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>,
	Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: [patch 134/149] x86, paravirt: Add a global synchronization point 
	for pvclock

On Tue, Jul 13, 2010 at 4:49 PM, Jeremy Fitzhardinge <jeremy@...p.org> wrote:
>
> The documentation makes no reference to that property; in fact it
> suggests it is outright not true:

The gcc documentation wrt inline asm's is totally worthless. Don't
even bother quoting it - because the gcc people themselves have never
cared. If the docs ever end up not matching what they want to do, they
will just change the documentation.

In other words, at least historically the docs are not in any way
meaningful. They are not a "these are the semantics we guarantee",
they are just random noise. As I mentioned, the docs historically just
said something like "will not be moved significantly", and apparently
they've been changed to be something else.

The only thing that has ever been meaningful is "this works". And, of
course, that has changed over time too, including actual
recommendations on how to make something work (as mentioned, iirc "+"
was only valid on register constraints, and "+m" used to not be
allowed _or_ recommended, these days it's the only way to do certain
things).

It's irritating, because in other circumstances, gcc people take the
reverse approach, and consider paper documentation more important than
actual implementation issues.  So sometimes they say "hey, this is the
spec", but when it comes to their own docs, the answer has
historically been "we'll just change the spec".

                         Linus
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ