Re: Summary of the ARM ports BoF at DC15
On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote:
> armel
> =====
>
> [...]
> Known worries/issues:
>
> * Kernel size due to very restrictive flash space; has been a
> problem, but not believed to be affecting current users so much
> now. Several problematic sub-arches have been dropped. The ixp
> flavour is *definitely* not going to be supported for another
> release. We've suggested in the past that the way to work around
> the restrictive flash space would be to write a trivial bootloader
> but there's not been any effort spent there.
The size restrictions encoded in the kernel are the lowest-common
-denominator, which I'm not sure really reflect the systems people are
actually using. While those do have limited amounts of flash are not as
constrained as the worst cases.
> * There's a good chance that we've built some things that don't work
> on v4t already, due to not using v4t hardware for build and test
> any more. That was already likely when we were using v5 buildd
> hardware, and it's only going to become more of an issue now we're
> using v7 buildd hardware. We *might* have to shift to v5 at least
> there are only a tiny number of v4t devices that people care about
> any more, it seems
FWIW I think shifting to v5 would be fine (the more so that we've
perhaps already done so by accident).
> Summary: if people care about armel for Stretch, they should make
> noise NOW and convince people it's needed and can/should be supported
> in future.
I think there are people who still care about specific subarches (or
actually, one specific subarch).
In particular the kirkwood subarch is still an interesting/active
platform which people use (due to being included in all sorts of NAS
devices etc) and which I at least do care about. I think kirkwood at
least will be viable through the lifetime of stretch and that makes it
worth continuing to support armel.
The other two subarches in the kernel are orion5x and versatile. I have
no personal interest in either. My gut suggests that orion5x (the
Marvell variant prior to kirkwood) is the one people might more
plausibly still be interested in, but I don't know that any is actually
still using it.
I think all of those 3 subarches are v5, and kirkwood certainly is, so
no need for v4t from that PoV.
> Buildds and hardware
> ====================
>
[...]
> Some of the software for armel cannot run on the arm64 machines,
> unfortunately. There are ARMv4t instructions that trigger exceptions
> due to missing support in ARMv8 CPUs. This will be another problem for
> armel as we move forward. Kernel exception handling will allow this
> code to work in future, but *massively* slower than if supported in
> the hardware so it's not really an option for us.
I'm sure they will be slower, but I'm not sure that v5+some emulation
running on a 2GHz ARMv8 server SoC will be "too slow" compared to
running natively on a 500MHz embedded SoC. IOW I'm not sure they will
be unusably slow. I guess we will see.
Does this issue go away entirely if we move from a v4t to v5 base, or
are there also v5 instructions which are (potentially) absent in v8? (I
think so, but I don't have my references to hand).
Aren't most such instructions related to SMP (so from userspace PoV
effectively to multithreading)? How much multithreading is there
actually in building packages I wonder. Neither gcc nor make link
against libpthread on this machine at least. Or do they affect
multiprocess stuff like e.g. futexes as well? Another "I guess we will
see", I suppose.
Ian.
Reply to: