On 09/08/2014 01:59 PM, H. Peter Anvin wrote:

On 09/08/2014 10:52 AM, One Thousand Gnomes wrote:

quoted

On Fri, 05 Sep 2014 08:41:52 -0700
"H. Peter Anvin" [off-list ref] wrote:

quoted

On 09/05/2014 08:31 AM, Peter Hurley wrote:

quoted

Which is a bit ironic because I remember when Digital had a team
working on emulating native x86 apps on Alpha/NT.

Right, because the x86 architecture was obsolete and would never scale...

Talking about "not scaling" can anyone explain how a "you need to use
set_bit() and friends" bug report scaled into a hundred message plus
discussion about ambiguous properties of processors (and nobody has
audited all the embedded platforms we support yet, or the weirder ARMs)
and a propsal to remove Alpha support.

Wouldn't it be *much* simpler to do what I suggested in the first place
and use the existing intended for purpose, deliberately put there,
functions for atomic bitops, because they are fast on sane processors and
they work on everything else.

I think the whole "removing Alpha EV5" support is basically bonkers. Just
use set_bit in the tty layer. Alpha will continue to work as well as it
always has done and you won't design out support for any future processor
that turns out not to do byte aligned stores.

Alan

Is *that* what we are talking about?  I was added to this conversation
in the middle where it had already generalized, so I had no idea.

No, this is just what brought this craziness to my attention.

For example, byte- and short-sized circular buffers could not possibly
be safe either, when the head nears the tail.

Who has audited global storage and ensured that _every_ byte-sized write
doesn't happen to be adjacent to some other storage that may not happen
to be protected by the same (or any) lock?

Regards,
Peter Hurley