Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:
>[ intentionally keep d-d CCed ]
>
>On Fri, 22 Jul 2016 02:36:05 +0100
>Steve McIntyre <steve@einval.com> wrote:
>
>> [ Please note the cross-post and Reply-To ]
>>
>> Hi folks,
>>
>> As promised, here's a quick summary of what was discussed at the ARM
>> ports BoF session in Cape Town.
>
>Thanks for the summary!
>
>I'm ARM porter on armel/marvell (orion5x/kirkwood).
>Stretch will be frozen and released soon, which makes me bit depressed,
>because it means armel will be dropped out of unstable/testing as the
>conclusion of Cape Town BoF.
>
>So I'm writing to ask if there's any chance ...
>
>> We spoke about the past/present/future state of ARM ports in Debian.
>>
>> armel
>> =====
>>
>> armel is the longest-running of our current ARM ports in Debian,
>> starting in 2007. It's starting to become difficult to support. Debian
>> is the only common distro still supporting ARMv4t. While there is
>> still good upstream support in most major packages (e.g. Linux and
>> gcc), we're seeing a growing number of issues. Some packages
>> (e.g. NodeJS) don't support pre-ARMv7 at all any more. Another problem
>> is the lack of direct support for C++11 atomics - it's possible to use
>> a kernel helper to cover for this lack, but performance will be
>> terrible.
>>
>> Possible future options for armel:
>>
>> * Partial armel architecture?
>>
>> We've talked about this in the past for various architectures, but
>> nobody has stepped up to work on it. The vast majority of the
>> outstanding armel use cases are going to be in headless servers so
>> we could maybe drop the desktop tasks and dependencies and keep
>> things like web server / mail server tasks that are much simpler.
>>
>> Downside: There's no clear plan for how to create/maintain a
>> partial architecture, let alone how to release one. Potentially
>> huge amount of work needed.
>>
>> * Update to ARMv5t (and maybe go headless)
>>
>> We might be able to extend the life of armel by upping the minimum
>> spec, and would be able to continue supporting Kirkwood and Orion
>> based machines (e.g. NAS boxes) for a while longer. This would kill
>> support for v4t devices like Openmoko, but there are precious few
>> of these older devices still around.
>
>Dropping v4t devices seems won't cause big problem, as you said
>there's few devices around currently. So I personally prefer this
>option.
AFAIK there are potentially still similar problems with ARMv5 - lack
of architcture-defined barrier primitives for C++11 atomics to
work. (I'd love to be corrected on this if people know better!) This
is one of the key points here. More and more software is expecting to
use these primitives, and a lack of them is a major problem. To
demonstrate using gcc, you can see that lock-free atomics only started
appearing in ARMv6 and were improved in ARMv7:
$ for arch in 4 5 6 7-a; do echo ARMv${arch}; echo | g++ -march=armv${arch} -dM -E - | grep -i lock_free; done
ARMv4
#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
#define __GCC_ATOMIC_POINTER_LOCK_FREE 1
#define __GCC_ATOMIC_INT_LOCK_FREE 1
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
#define __GCC_ATOMIC_LONG_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
ARMv5
#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
#define __GCC_ATOMIC_POINTER_LOCK_FREE 1
#define __GCC_ATOMIC_INT_LOCK_FREE 1
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
#define __GCC_ATOMIC_LONG_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
ARMv6
#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
ARMv7-a
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
#define __GCC_ATOMIC_SHORT_LOCK_FREE 2
There are kernel helpers available to provide some atomic support, but
they'll be very slow compared to real hardware support at this level.
>> Downside: as above if we try to do the partial architecture route;
>> if we don't we'll still have to support a full range of software on
>> older hardware.
>
>I don't see any detailed downside reason here. I think armel dropping
>v4t is just like i386 dropping 586-class CPU [0]. If we can dropping
>586-class CPU support for i386, by changing a few configure files in
>gcc/dpkg/kernel packages, why we cannot do the same for armel?
It's a similar thing, but further up the curve - that's all. We added
armhf (as the equivalent of i686, maybe) a while back, targeting
ARMv7. The much older CPU designs based on ARMv4 and ARMv5 are getting
harder to support than the i586 here. The world has moved on,
basically.
>[0] https://lists.debian.org/debian-devel-announce/2016/05/msg00001.html
>
>I'm a "high-level" ARM porter, merely knowing the basic device-tree
>stuff to support new device. So I'm lack of knowledge in lower
>chipset level and maybe missed something here. Could you kindly help
>to list the detailed work other than listed above?
>
>> Will need volunteers to make this work in either form, and while
>> some people are prepared to *help* (e.g. bdale and zumbi), nobody
>> stepped up in the BoF to lead such an effort. It needs both skill
>> and commitment of time.
>
>If specific working items are clearly listed, I think there would be someone
>stepping out, since the armel user/devel base is still big.
You're the first armel developer to offer to dive in here, so that's a
good start!
* It will need somebody happy to dive into the lower levels of the
various toolchains to verify support for atomics and make things
work where it's not already, by adding support for the kernel
helpers.
* *If* we wanted to try the partial architecture thing, that will
need some effort to make it work. That's not well-defined right
now, as it's only a vague concept at best (sorry!)
* There are going to be some packages that just won't work,
particularly JIT compilers and other code generators that assume
ARM == ARMv7. Fixing those up might raneg between feasible and
~impossible depending on the size of the codebase...
>Thanks and look forward to your feeback!
HTH!
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Mature Sporty Personal
More Innovation More Adult
A Man in Dandism
Powered Midship Specialty
Reply to: