Dear Steve, Thanks for your comments! Very informative!
On Thu, Dec 8, 2016 at 12:53 AM, Steve McIntyre <st...@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