[ 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. > 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? [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. Thanks and look forward to your feeback! Cheers! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Attachment:
pgpnrdQt5UXXO.pgp
Description: PGP signature