Re: armel after Stretch
Dear Steve,
Thanks for your comments!
Very informative!
On Thu, Dec 8, 2016 at 12:53 AM, Steve McIntyre <steve@einval.com> wrote:
>
> There are kernel helpers available to provide some atomic support, but
> they'll be very slow compared to real hardware support at this level.
Are those kernel helper already reached Debian?
Or there's still some work here?
>>> 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.
Just like the world already moves on to amd64, but Debian still
support i386 and i686,
I think the community need armel and armhf, for quite a long time if
it's feasible.
> You're the first armel developer to offer to dive in here, so that's a
> good start!
Thanks, but my knowledge don't cover the lower part such as building toolchains,
still need someone with more experience.
> * 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.
> On Wed, Dec 07, 2016 at 05:05:58PM +0100, Emilio Pozuelo Monfort wrote:
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820535
>>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735
I guess above 2 links, provided by Emilio (thanks so much!), can
resolve the concern on building toolchains.
> * *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!)
Maybe we can avoid to do partial arch?
> * 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...
If something breaks, I guess it breaks now already.
We need to fix before Stretch.
If the issue is fixed, I think there's no need to remove armel
immediately after releasing Stretch.
Please correct me if I missed something. Thank you!
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Reply to: