On 2019/08/12 08:46, Theo de Raadt wrote: > Stuart Henderson <s...@spacehopper.org> wrote: > > > On 2019/08/12 14:12, adr wrote: > > > > It's not clear to me that assembly code is the culprit here. > > > > > > No, I bet it is their memory managment functions. > > > > > > > I agree with Stuart's statement. It may be terse but I don't find it > > > > pedantic. > > > > > > And I agree too, that's why I found it pedantic. > > > Any way, I'm out of place here. > > > > The problem with changing things in each port is that it will take > > forever (apart from anything else there are very few ports developers > > with armv7 machines) and it's likely a never ending battle. Few port > > maintainers are going to be able to test diffs. And disabling asm is > > unappealing on an arch which needs as much help with speed as it can > > get. > > > > Looking in list archives I see patrick@ mentioned about running in > > strict alignment mode and the ecosystem not being really able to support > > that in reply to your earlier post about x264. And as you can see in the > > thread I linked to earlier there is some appetite and an initial diff > > for changing this. It's likely that such a change will result in the > > most things being fixed for the least effort. > > Let me explain why we've tried to run strict alignment on as many > platforms as possible. > > It is because some architectures are data strict alignment. We could > emulate non-strict on the strict platforms, and make them all non-strict > alignment. That is the direction Linux has been going, and that's why > so much code is written that way now. > > There are a few problems with this: > > Some architectures have a cheap toggle to do non-strict in hardware, or > can be emulated inexpensive. But on other architectures the emulation > is very expensive: read the instruction, decode it, and then emulate the > behaviour, all the time ignoring the lack of atomicity introduced by the > emulation which may cause other problems later in threaded code and > such. > > So let's say we do non-strict on some architectures, but not others? > > Sooner or later, the strict architectures are going to be the only ones > which get burned by a software change which assumes all the world is a vax. > (vax was non-strict) > > Some of the strict-alignment platforms are slower, and due to having a > smaller user base, repair for these issues will take longer. Eventually > support for those architectures becomes extinct. > > And becoming extinct is a bad thing. We are using the breadth of > architecture variety as a "canany in the coalmine" approach towards > identifying bugs which may affect more than just one architecture. > Running on lots of tier2 architectures improves quality for our tier1 > platforms, this is no joke. > > In the end, even amd64 will suffer from the lack of testing diversity. > > We could give up on strict-alignment on arm64, but the consequences is > other architectures will become 'load bearing' for this issue. > > First they came for strict alignment on arm64, but I wasn't arm64 so > I didn't say anything. >
I fully understand this. (And that aligned access is faster on !strict arches). With arm64 the machines are fast enough, there's a bit more developer interest, and I think there probably *are* enough in hands of ports devs that we maybe able to cope with this approach. For armv7 that the OP is using, it's going to be hard for ports to cope.
