User: Password:
|
|
Subscribe / Log in / New account

Why bother supporting ARM?

Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

By Jonathan Corbet
April 4, 2012
Two weeks ago, LWN covered the debate within the Fedora project over whether its ARM port should be designated one of that distribution's "primary" architectures. That discussion has progressed a little further, so an update may be warranted. But it may also be worthwhile to address a related question: why is there resistance to the concept of supporting ARM as a primary architecture in the first place? And why might it make sense to promote the ARM architecture anyway?

One of the things that came out in the original discussion is that the Fedora project did not have any idea of how to do that. Over its entire history, the project has never before seriously considered moving one of its secondary architectures to primary status. So there are no procedures in place and no criteria by which a decision to promote an architecture can be made. So, unsurprisingly, the project decided that it needs to come up with a set of reasonable criteria. On April 2, Matthew Garrett posted a draft showing what those criteria might look like.

The rules would appear to make sense. The Fedora infrastructure and release engineering teams need to have people who are able to represent any new primary architecture. The project must be able to build packages on its own servers. Anaconda, the Fedora installer, must work on the targeted hardware. Maintainers of important packages must have access to the supported hardware so they can fix problems. No binary blobs. And so on. Also required is approval from various Fedora teams, each of which can impose additional criteria if it sees the need. These rules are in an early form and can be expected to evolve over time, but the early responses on the mailing list suggest that most people are happy enough with what has been set down.

That said, there are clearly some people who do not see the point of supporting ARM as a primary architecture, and they have a number of reasons for their reluctance. The ARM architecture is messy, for example. The x86 architecture does not have a single design authority, but processors made by multiple vendors still resemble each other closely enough to create a fairly tightly-knit processor family. ARM does have a central design authority, but that authority leaves a lot of significant details up to individual manufacturers, of which there are many. So ARM is not a tightly-knit family; it is more like an extended group of hostile ex-spouses and in-laws who have moved to different continents to get away from each other.

The looseness of the ARM "platform" had led to a lot of innovation in the design space; there is no end of interesting ARM system-on-chip designs with all kinds of impressive integrated peripheral devices. But this diversity, along with a distressing lack of hardware discoverability, makes it impossible to create a single kernel that works on all (or even a significant subset of) ARM processors. Distributors hate having to maintain multiple kernels, and they hate having to put target-specific hacks into installers. ARM currently forces both, despite the ongoing work to consolidate kernel code and move hardware knowledge into the bootloader-supplied device tree structure.

ARM is also, for many developers, a relatively obscure architecture lacking the familiarity of x86. The fact that there are vastly more ARM systems running Linux than x86 systems does not really change that perception; most of us lack ARM-based development systems on our desks. Additionally, ARM processors are relatively slow. That is a problem for developers, who typically need to keep an x86 system and a cross-compiling toolchain around to be able to get through more than one edit-compile-test cycle in any given day. That slowness is also an issue for distributors; it can delay security updates and distribution releases, even for other architectures. And, while the hardware is slow, product cycles are fast; by the time developers have gotten a target working nicely, it may be obsolete and off the market.

Given all of these challenges, it is not surprising that some people would rather not be bothered by an architecture like ARM. The x86 world provides plenty of open, high-performing systems with wide support; why get distracted with that messy architecture where, even if the distribution can be made to work, the hardware is probably closed and won't allow it to be installed?

The answer, of course, is that said messy architecture is already performing much of our computing, and it will likely be doing more of it in the future. Traditional PC-style systems are no longer the center of attention; one assumes they will not go away entirely, but a lot of the action is elsewhere. There is a whole new crowd of makers looking to do interesting things with ARM-based designs; we are just beginning to see what can be done with interesting mobile devices, and the bulk of those devices are not, at this point, using x86 processors. Meanwhile, ARM has its eyes on data center applications where, some think, its compactness and power efficiency will make up for its lack of speed. The x86 architecture will be with us for a long time - even Intel has proved unable to kill it off in the past - but it is far from the only show in town.

It is also worth remembering that, for all its success, Linux is still a minority player on x86 systems. But Linux is the dominant system on ARM-based systems. The "year of the Linux desktop" may be an old and sad joke, but the year of the Linux gadget looks to be happening for real - again.

Given that ARM is where much of the action is, it would make sense that a Linux distribution - especially one that is supposed to be leading-edge and forward-looking - would want to support ARM as well as possible. Solid support for the architecture seems like a necessary precondition for any sort of presence in the interesting computing devices of the near future. Distributors like Ubuntu appear to have come to that conclusion; they have built on Debian's longstanding ARM support to create a distribution that, they hope, will be found in future devices. Without well-established ARM support, Fedora - along with the distributions derived from it - has little chance of competing in that area.

So one might well say that the questions being asked in the Fedora community are wrong. Rather than asking "why should we support ARM when it presents all of these difficulties?", it might make more sense to ask "how can we address these difficulties to provide the best ARM-based distribution possible?". The cynical among us might be tempted to say that Red Hat, Fedora's sponsor and main contributor, faces a classic disruptive technology problem. ARM is unlikely to displace x86 in the places where Red Hat currently sells support, and revenues from any future ARM-based "enterprise" distribution seem likely to be rather lower than those obtained from x86-based distributions. So it would be understandable if Red Hat were to show a lack of enthusiasm for the ARM architecture.

The cynical view is, at best, only partially right, though. Red Hat does not advertise the resources it is putting into ARM distribution development, but it clearly has a number of engineers on the task. Even as a "secondary" architecture, Fedora's ARM distribution has been solid enough to serve as the base for the ARM-based OLPC XO 1.75 laptop. Without Red Hat's support, there wouldn't be a Fedora ARM distribution even with secondary status. So it seems unlikely that Red Hat is the sticking point here, even if its contributions to the kernel's ARM subtree (29 patches total from 3.0 to the present) show little enthusiasm. More likely we're just seeing the usual noise as the wider community comes to terms with what will be required to support this architecture properly.

In the end, the world would not be well served by a single processor architecture; there is value in diversity. Similarly, an industry where ARM-based systems are dominated by Android variants may not be the best possible world. A lot of interesting things are happening in computing, and many of them involve the ARM architecture; there is a lot of value in having strong community-based distribution support for that architecture. That is why Fedora will, in the end, almost certainly bother to support ARM as a primary architecture despite the challenges it presents.


(Log in to post comments)

Why bother supporting ARM?

Posted Apr 5, 2012 5:31 UTC (Thu) by jmorris42 (guest, #2203) [Link]

Until ARM hardware becomes real instead of theory itis hard to imagine it a primary target. Fedora doesn't allow binary blobs and it the rare ARM product that doesn't require one. Rarer still is finding one a normal end user can install an OS on. Opening it up and installing a serial console port is not an end user operation.

Since Fedora doesn't allow cross compiling it will also be a requirement that at least ONE suitable build host be available for purchase that isn't an overpriced protoboard and has sufficient CPU and RAM to permit building largish C++ projects in a reasonable time. A package maintainer should be expected to maintain their package on all primary platforms and if they can't buy one of those platforms that becomes an unreasonable expectation.

Bottom line, Fedora is not a cross compiled embedded distribution like OpenWRT and until ARM products evolve out of that niche into self hosting hardware it is going to be a poor fit.

Why bother supporting ARM?

Posted Apr 5, 2012 6:00 UTC (Thu) by tajyrink (subscriber, #2750) [Link]

I guess that just shows how different views people having, something the article also well put out.

I've been using Debian on my NAS and phone for years. The NAS did require a flashing operation first, after which a friendly debian-installer answered over SSH (http://www.cyrius.com/debian/orion/qnap/). The phone was installable very easily by executing one script.

Debian buildd:s are also native builders, as are Ubuntu's, MeeGo's and openSUSE's. Granted the builder RAM/CPU is a problem, but even Qt and open/libreoffice kind of things have been built for a long time now, and it's becoming less painful every month (1-2GB RAM and quad-core goes a long way).

But this article gives a very good perspective, and goes some way in explaining why for example the mobile application development (ie. targeting many of the ARM devices) hasn't picked up that well yet in the free software land. Many, many people are very x86/desktop oriented, and the change will happen gradually over a long time.

Why bother supporting ARM?

Posted Apr 5, 2012 12:12 UTC (Thu) by wookey (subscriber, #5501) [Link]

Quite. The idea that ARM hardware isn't 'real' looks really strange from where I sit. I've had arm-linux servers since 1997. First a riscix box that ran the mail and ISDN connection, then a range of Debian machines: netwinder, slug, balloon, panda.

This isn't as 'new' as most people think it is, it's just been something of a niche. Quite what makes you think hardware is overpriced I don't know.

As tajyrink said we've been natively building everything in Debian on ARM since 1999. Yes the biggest packages are always at the limit of the hardware (you didn't need 1Gb RAM to link things back in 2000 fortunately), but it works fine. ARM has been self-hosting for a decade already.

Package maintainers are supported in Debian by the distro supplying 'porter' machines. (No-one can be expected to own their own hardware for every possible architecture). But it's also easy for packagers to get hardware if they want. Any of these could do the trick:

Toshiba AC100, efika smartbook/smarttop, sheevaplug, pogoplug, dreamplug, pandaboard, solidrun cubox (not quite shipping yet, but I saw some nice hardware in feb). Installation is perfectly 'end-user' on all of those SFAIK: shoving an SD card in or running a distro installer.

Why bother supporting ARM?

Posted Apr 5, 2012 23:17 UTC (Thu) by justincormack (subscriber, #70439) [Link]

The cubox shipped at last... well mine has.

Why bother supporting ARM?

Posted Apr 5, 2012 6:26 UTC (Thu) by nhippi (subscriber, #34640) [Link]

> Fedora doesn't allow binary blobs and it the rare ARM product that doesn't require one.

How does fedora support Wifi then... Even most intel wifi chips needs firmware.

It is true that mobile ARM devices need binary blobs to exploit the hardware fully, but that is also true for most X86 desktop and mobile machines too.

But OTOH many ARM NAS products come completely void of binary blobs, including not having a proprietary BIOS but booting with open source uboot. Sheevaplug and other Marvell Kirkwood devices around for example.

Btw sheevaplug serial console is reached by plugging in a miniUSB cable. That would be an awesome feature for headless x86 servers well.

Fedora ARM being secondary arch is going to look rather silly if soon there are more ARM fedora machines (for example a modest batch of OLPC 1.75 machines) out there than X86 machines with fedora...

miniUSB console

Posted Apr 5, 2012 11:40 UTC (Thu) by robbe (subscriber, #16131) [Link]

> Btw sheevaplug serial console is reached by plugging in a miniUSB cable.
> That would be an awesome feature for headless x86 servers well.

Indeed. Current Cisco switches also have these (in addition to a more traditional console port).

Why bother supporting ARM?

Posted Apr 5, 2012 12:41 UTC (Thu) by pjones (subscriber, #31722) [Link]

> How does fedora support Wifi then... Even most intel wifi chips needs firmware.

We make a distinction between binary blobs that run on the host cpu in the kernel's memory and firmware that runs on an peripheral's cpu and memory. The former we don't allow, and that's the concern being raised. The latter, we consider to be effectively part of the peripheral hardware.

Why bother supporting ARM?

Posted Apr 6, 2012 9:47 UTC (Fri) by arnd (subscriber, #8866) [Link]

Generally speaking, binary blobs tend be required for graphics on ARM, while headless systems can usually run a 100% free software stack. Kirkwood happens to be a soc family that does not come with any on-chip graphics, it's easy for those to be very open. Things are slowly changing for those chips with graphics too, and we're seeing a lot of work going into opening up the display subsystem, which allows unaccelerated graphics, and there is some work at reverse engineering some of the GPU drivers as well.

Why bother supporting ARM?

Posted Apr 5, 2012 8:13 UTC (Thu) by jcm (subscriber, #18262) [Link]

ARM hardware is pretty "real" :) It's true that we're using development boards for builders at the moment, but that will change (I dispute "overpriced" - all of our hardware is under a few hundred bucks). The user base is different in the ARM case. On the high end, there will be people with appliance-like servers. On the medium end, you will find development-like boards with serial consoles as well as framebuffers. On the low end, you will see inexpensive hardware of use to the hobbyist community. All of these are viable and excellent Fedora users. Fedora doesn't do mass market consumer anyway, so if the kinds of people into ARM aren't "Fedora people", who are?

There are increasingly fewer binary blobs, but there is more work to be there (and it is happening). I think it is necessary to also distinguish between e.g. tablets not intended as general purpose hardware wherein you can shoehorn Fedora ARM but you will run up against these issues, vs. the more general purpose hardware that is here and in the works. We might only have 1GB RAM in many of our systems today, but this year, you will see 4GB systems, and next year there will be much higher still.

Why bother supporting ARM?

Posted Apr 5, 2012 14:00 UTC (Thu) by jmorris42 (guest, #2203) [Link]

> ARM hardware is pretty "real" :)

Oh for sure. It is in my TV and phone and I have gained root on both of those as well as some little NAS boxes at work to add some extra packages. Wouldn't want to try running Fedora on any of those and as for development, just no.

> It's true that we're using development boards for builders at the
> moment, but that will change (I dispute "overpriced" - all of our
> hardware is under a few hundred bucks).

Riddle me this: Other than being able to build a Fedora package for use on other hardware, of what use is one of those development boards for 99% of Fedora developers? Is making owning one a baseline requirement to become a Fedora developer a reasonable expectation?

> We might only have 1GB RAM in many of our systems today, but this
> year, you will see 4GB systems, and next year there will be much higher
> still.

Of course, Moore's Law grinds on. And when such hardware is widely available would be the time to take up the question of making it a primary platform. Gotta get the cart and horse in the right order. Now though, the hardware that is actually available is more suited to embedded operating systems.

We first need to discover if this upcoming generation of hardware is even going to be made available to us. Remember that this push to ramp up the capabilities is intended to host Windows 8 and it is all going to be the most severely DRM locked hardware yet produced. If it is locked as well as a PS3 we are screwed. And of course if they get away with it they will be bringing the chains to x86. Dark times.

Why bother supporting ARM?

Posted Apr 5, 2012 12:46 UTC (Thu) by Da_Blitz (subscriber, #50583) [Link]

The multitude of tablets, laptops and phones out there would more than prove arm hardware is real and not theory. i own quiet a few arm devices and in nearly all cases binary blobs are only needed for graphics acceleration, if you are not watching moives or playing games and are instead looking to do some work on these devices then this is not much of an issue

buildhost wise there are a number of ways to tackle this and is something where ubuntu is way ahead with their build cluster, it has been noted that the arm build cluster is slower than the x86 one but i am sure this is something that could easily be corrected with some more boards. manufacturers only putting in 1GB of ram due to hardware or price limitations does appear to be an issue as well for larger compiles

i run and use linux on an arm laptop for day to day use and would love to be running fedora on the machine. i treat it like an older x86 machine in regards to my setup choices and it responds well to that i dont believe you need a built for cross compiling OS like openWRT for these devices. just realize they are a bit slower expect the horse power out of them that an atom has or older laptop rather than comparing and expecting i7 like performance

Why bother supporting ARM?

Posted Apr 5, 2012 6:21 UTC (Thu) by iabervon (subscriber, #722) [Link]

I'm not actually sure that it makes sense to run Fedora on your gadget. Or, rather, I'm not sure that it makes sense to share a package selection between gadgets and PC-style systems. Sure, it would be good to eliminate the need to separately maintain things like libc and openssl, but it doesn't make sense to expect GNOME to work equally well on your laptop and your thermostat. This doesn't mean that PC-style systems with ARM processors shouldn't be supported in distros, but they're a small portion of the ARM-processor-based install base, as well as being a small portion of the PC-style-systems install base.

I think it would make sense to have a handheld distro with more overlap with PC distros than an embedded distro would have, but I think they're still different enough that the default situation would be that packages for PCs wouldn't apply to handhelds.

Why bother supporting ARM?

Posted Apr 5, 2012 12:49 UTC (Thu) by drag (subscriber, #31333) [Link]

My phone is much more powerful then a PC that I had years ago and it happily runs Debian in a chroot environment and is useful.

Why bother supporting ARM?

Posted Apr 5, 2012 15:23 UTC (Thu) by jwarnica (guest, #27492) [Link]

The screen is not as big, and likely not to the same resolution. The keyboard is not the same, the mass storage is not there. The workload done on them is very different.

A desktop PC and a phone, or even tablet, just fill fundamentally different purposes.

That they happen to be both turing complete, or able to actually run the same software is entirely irrelevant.

Why bother supporting ARM?

Posted Apr 5, 2012 15:42 UTC (Thu) by fatrat (subscriber, #1518) [Link]

They are different now, but not for long. Already phones run 1024x768 type resolution, can drive external monitors and use external keyboards.

Why bother supporting ARM?

Posted Apr 5, 2012 16:43 UTC (Thu) by iabervon (subscriber, #722) [Link]

But your phone's screen will (hopefully) never occupy 30 degrees of your vision like your computer's monitor probably does. It's not just the number of pixels, it's the number of letters your eyes can distinguish on the screen. And, while you may be able to attach a keyboard and monitor and interact with it like a PC, the normal situation will be that you only have the built-in hardware handy when you want to use it. Not to mention that your phone has a much higher chance of getting dropped and run over by a truck.

And, while phones are moving from "definite gadget" to "always gadget, sometimes also PC", there are plenty of ARM-based systems that are definitely not; you're not going to plug an external monitor and keyboard into your desktop computer's hard drive, even though it's also likely to have a more powerful processor than your first Linux PC before long. If anything, the popularity of non-PC gadgets which could sensibly run Linux (relative to PCs) is going to increase over time as more devices which were traditionally mechanical or hard-coded become smart. (I really want to run Linux on my washing machine. It's a great piece of equipment, but it doesn't always have a program for what I want.)

Why bother supporting ARM?

Posted Apr 5, 2012 16:58 UTC (Thu) by Cato (subscriber, #7643) [Link]

This isn't just about phones, it's about tablets, some of which have optional keyboards in a laptop format. And phones can be plugged into large displays these days (iPhone 4S and others).

Why bother supporting ARM?

Posted Apr 5, 2012 17:28 UTC (Thu) by khim (subscriber, #9252) [Link]

But your phone's screen will (hopefully) never occupy 30 degrees of your vision like your computer's monitor probably does.

Why not?

And, while phones are moving from "definite gadget" to "always gadget, sometimes also PC", there are plenty of ARM-based systems that are definitely not; you're not going to plug an external monitor and keyboard into your desktop computer's hard drive, even though it's also likely to have a more powerful processor than your first Linux PC before long.

I don't think there are any plans to target all ARM devices out there with a single Fedora image.

Why bother supporting ARM?

Posted Apr 5, 2012 16:51 UTC (Thu) by Cato (subscriber, #7643) [Link]

The GPUs on ARM-based phones and tablets are also quite powerful these days, and in some cases can drive a 1080p HDTV (e.g. iPhone 4S and iPad 2+) - http://www.iphoneforums.net/forum/iphone-news-site-news-7... is one example.

With Bluetooth for the slower peripherals and HDMI (or a future wireless HD connection), you should ultimately be able to just walk into a room with the right kit and use your phone/tablet as the engine for a PC-like setup with large screen, keyboard, gaming controller, etc.

Gadgets can be bigger than mobiles...

Posted Apr 5, 2012 6:47 UTC (Thu) by rsidd (subscriber, #2582) [Link]

Just to remark that ARM "gadgets" these days include tablets, which are as powerful as netbooks if not more so, have phenomenal battery life, and can be converted to laptops with attachable keyboards -- either vendor-supplied (Asus Transformer) or third-party. I myself use an Android tablet with a Linux chroot environment and a keyboard-case -- when using it as a tablet I use the Android environment, and when using it as a laptop I use the chroot environment with an XFCE desktop, and it works great. Ubuntu is pushing "Ubuntu for Android" for similar reasons. I fully expect Windows 8 tablet/laptop hybrids to be out within the year. These will be productivity machines, not toys. It would be a pity if "real" Linux misses this space, yet again.

Gadgets can be bigger than mobiles...

Posted Apr 5, 2012 16:58 UTC (Thu) by jmorris42 (guest, #2203) [Link]

> I myself use an Android tablet with a Linux chroot environment and a
> keyboard-case -- when using it as a tablet I use the Android environment,
> and when using it as a laptop I use the chroot environment with an XFCE
> desktop, and it works great.

As a hack it is a marvel. As a practical thing I have to question the value proposition. If we take it as read that GNOME/etc on a phone or tablet makes no sense (there goes the whole reason for GNOME3 but that is a story for another day) and that Android in tablet or phone mode is the best fit then I have to question the utility of hosting a seperate desktop environment on the tablet or phone.

Think this through with me and tell me where I'm missing the boat. Option one is to do what you are doing and simply connect an external head, leaving all storage, computing and connectivity on the small device. Option two is to just leave the user's files on the small device and have the head plus a CPU (say an Atom) on the dock along with much faster and larger storage for applications and media. Connectivity can go either way depending on the situation. In the real world an Atom or other low end x86 tethered via USB to the tablet/phone will cost about the same as the specialized dock and run circles around any ARM. Yes, if docks became both popular AND standardized enough for serious economy of scale that would change but in two decades of laptops it hasn't worked out that way so I wouldn't bet on it being different now.

The only remaining advantage would be the ability to drop into different docks and carry all of your state with you but that only matters as a general matter if they get standardized and very popular.

If you could run the same applications in both use modes a pure dock suddenly makes a lot of sense, but you have actually tried that and abandoned it, yet still see value in hosting the desktop on a puny mobile CPU. That is apparently also Ubuntu's conclusion as well, hence my question.

Gadgets can be bigger than mobiles...

Posted Apr 6, 2012 1:38 UTC (Fri) by rsidd (subscriber, #2582) [Link]

For me it is extremely practical. I think what you are missing is that it is a 10 inch screen, similar to a netbook. I don't need an "external head", just a "keyboard case" (looks like a regular leather folding case, but with a keyboard built in, and opens out like a laptop). The pointing device is the screen itself. I am typing this on that machine. I have put together 45 minute presentations (in LaTeX beamer), viewed and edited documents in libreoffice, etc, done some python programming. When I'm done I can slide it out of the case (or just fold it backwards) and use it like a tablet, if I want (kindle, browsing, games).

Sure it's a hack -- eg I view it with a VNC viewer on android, and it only runs xfce because I couldn't get other things running on it. But if a manufacturer took interest, it would be another story. Ubuntu for Android should be targetting this sort of device, not phones.

Gadgets can be bigger than mobiles...

Posted Apr 12, 2012 9:02 UTC (Thu) by kragil (guest, #34373) [Link]

This sounds really interesting. May I ask which tablet and keyboard case you use exactly and which distro you run?

Gadgets can be bigger than mobiles...

Posted Apr 13, 2012 1:18 UTC (Fri) by jmorris42 (guest, #2203) [Link]

Other than Angry Birds, why use it as a tablet? Gimme that, perhaps with a little larger display, and I'd be happy too. But I'd just use it as an arm based netbook most of the time I'm away from the desk since you can't actually buy one of those. But when at the desk I like my big display, mouse and such. That is the use case Ubuntu appears to be going after and the one I question.

Why bother supporting ARM?

Posted Apr 5, 2012 8:05 UTC (Thu) by jcm (subscriber, #18262) [Link]

Just to add, an increasing amount of standardization is occurring in the ARM SoC space. Although there are limits to what I can say about that, I think it's fair to say that you can expect a lot more consistency around common platforms in the future. The latest versions of the architecture also increasingly standardize core features - floating point isn't an option on v7 and v8 cleans up even more of the vagueness that doesn't increase value by being left open.

Why bother supporting ARM?

Posted Apr 5, 2012 8:21 UTC (Thu) by myopiate (guest, #41091) [Link]

The windows programmers I work with have problems with Linux. They know windows and it's quirks from top to bottom. To them knowing these thigns are useful and it would take a significant investment to duplicate this knowledge for a second system.

There is windows software for Linux and Linux software that runs on Windows. Both platforms have independently leveraged off the other without being unified. Linux has its strengths and both of them have their weaknesses.

In that same way, x86 Linux users will have issue with other architectures and their quirks. To make it x86 go better you tweak this setting in your BIOS, probe the PCI for hardware and write your code like this to take advantage of the massive caches etc. etc.

I've have "brought up" ARM boards and built x86 PC's from parts. There is different mindset to both and I think this should be celebrated rather than one dictating the way the other should work. Enforcing the "x86" way of doing things on the ARM architecture will hamstring it to some of x86's flaws.

I reckon the best way is to continue Fedora ARM as a secondary Architecture, maintaining "Fedora for ARM" kind of like a distro in it's own right. Code sharing will still happen just as it does with Meego, Android and Fedora already. As more and more people buy products with ARM processors the community will grow, contributions will increase and the definition of what is a Primary Fedora Architecture will change to reflect the way that "Fedora for ARM" does things.

This is the way it should be. Demanding that x86 users support ARM is not the open source way.

Why bother supporting ARM?

Posted Apr 5, 2012 17:51 UTC (Thu) by jlayton (subscriber, #31672) [Link]

(I've been told much of this second-hand, so take it with a grain of salt)

One of the problems with making ARM a primary arch currently in Fedora is that kernel builds in particular can take days on stock ARM hardware. So, if you kick off a kernel build, koji won't call it "done" until the ARM build is done, and we'll end up with a massive bottleneck in the ARM build machines.

Fedora also has an explicit policy of not allowing cross-compiled packages, but that could be changed. Even if they were to allow cross-compiles though, there's the problem that there's no infrastructure in koji to do that at the moment. That would have to be added...

...and then we'd probably need a mechanism to whitelist certain packages that are cross-compilable. Not all are -- some might fail certain autoconf tests. They will need to be fixed in some fashion or built natively.

So, it's not something where you can easily say "just make ARM a primary arch now". There are a number of things that I think would need to happen in the build infrastructure first.

Why bother supporting ARM?

Posted Apr 5, 2012 18:21 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

Kernel builds take a long time, but not compared to say LibreOffice. The real problem for distribution kernel packages is the proliferation of configurations. In Debian we now have 6 configurations for the 'armel' architecture, covering various platforms with v4 and v5 processors, but even so LibreOffice takes about twice as long:

https://buildd.debian.org/status/logs.php?pkg=linux-2.6&...
https://buildd.debian.org/status/logs.php?pkg=libreoffice...

Future mainline changes may allow more different platforms to be supported in a single image and thus reduce the number of configurations needed. It should also be possible to build on faster ARM systems; currently the fastest build servers are running and building for the 'armhf' architecture but they could support an 'armel' chroot.


Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds