It's not the question of if, it's question when [LWN.net]

There is nothing wrong with use of the old version

Posted Nov 6, 2011 21:54 UTC (Sun) by khim (subscriber, #9252) [Link]

Do you use glibc 2.5 or have you ported linuxthreads to glibc 2.14?

Last time I've checked ARM for MMU-less CPUs had no support for glibc at all and was able to compile only tiny number of programs - usually old versions.

There are nothing wrong with playing with old/unusual hardware and software but it just makes no sense to worry about ARM for MMU compatibility when you develop libraries for modern Linux. Probably even less sense then trying to support Windows by default.

There is nothing wrong with use of the old version

Posted Nov 7, 2011 22:58 UTC (Mon) by jlokier (guest, #52227) [Link]

The GP comment seemed to imply that we should eliminate choice where it's no longer useful, and that NPTL is now good enough to be universal on Linux. Eventually I hope it is, there's no technical reason why it shouldn't be, but for the moment, there is still useful work being doing on Linux systems that NPTL doesn't yet support. That's all I wanted to point out.

No I haven't ported glibc. You wouldn't do that for a low-memory system (glibc is not small (but I look hopefully at eglibc)); uclibc is a better choice. I've built a Gentoo x86 system using uclibc in the past, so it's not impractical to use. There aren't a lot of glibc-isms in apps, and uclibc tries fairly hard to be compatible.

ARM with no MMU runs uclinux and uclibc, like anything with no MMU, and that's no too bad, there's quite a lot of software that builds on it.

There's only two real issues: No fork (affects fewer programs than you'd think), and no ELF shared objects, which is a bigger restriction as lots of things assume shared objects nowadays. Some no-MMU platforms do support ELF, and ARM could, but nobody's implemented it for ARM; I started, but had to move on. Almost everything else works the same as with MMU; file mmap is limited, but very few programs depend on it. And of course low memory, but that's not unique to no-MMU systems.

I accept the charge of unusual hardware, but just for some perspective: (a) count the number of home routers and set top boxes in the world; and (b) in the last 2 years I've worked for 4 different companies developing on no-MMU hardware, 3 of them ARM, and another architecture that I probably shouldn't name because it's not mainlined. Another no-MMU-only architecture got merged in Linux 3.1. It is niche, but it's still part of current Linux activity in the embedded universe, not limited to museum pieces. I would still strongly recommend choosing a chip with MMU if at all possible though, even for tiny systems :-)

Responding to "it just makes no sense to worry about ARM for MMU compatibility": Generally in a library, there's no need for specific "ARM-without-MMU" support. Assuming it works effortlessly on ARM (which it should these days), it would be just about the MMU, independent of CPU architecture. Which most things do fine, and a few need small changes.

I wouldn't be surprised if GNOME and Firefox worked with fewer changes than you'd expect on a no-MMU target (so long as it had ELF), even one still using LinuxThreads, if there was enough memory. But of course there isn't enough memory :-)

Well, people are free to do whatever they want with your library...

Posted Nov 8, 2011 7:23 UTC (Tue) by khim (subscriber, #9252) [Link]

Responding to "it just makes no sense to worry about ARM for MMU compatibility": Generally in a library, there's no need for specific "ARM-without-MMU" support. Assuming it works effortlessly on ARM (which it should these days), it would be just about the MMU, independent of CPU architecture. Which most things do fine, and a few need small changes.

That's fine. If your library is used on some exotic platform (be it Windows, VMS or ARM without MMU) then I see no problem with it. But if you start changing everything from the start to support them... that's another thing.