Unconventional Linux Tom spot Callaway <tcallawa@redhat.com May 10, 2007
Linux: Not just for x86 anymore Linux around the house Linux in your pocket Non x86 Servers Aurora SPARC Linux Secondary Architectures in Fedora
Architectures Supported in Linux Today Alpha MIPS Argonaut RISC Core (ARC) OpenRISC ARM PA RISC AVR32 PowerPC ColdFire S/390 (31 and 64 bit) ETRAX CRIS SPARC Fujitsu FR V SPARC64 H8 SuperH IA64 x86 M68K x86_64
TiVo: Linux + TV TiVo Digital Video Recorders run a customized version of Linux The first generation models were PPC systems (Series 1) More recent models use Broadcom MIPS64 CPUs (Series 2,3) While TiVo has released the sourcecode for the modifications that it made to Linux, the hardware will not run arbitrary Linux installs. It only boots official TiVo Linux kernels. This has become known as Tivoization, and the GPLv3 drafts have language specifically in them to prevent anyone from using GPL code with hardware in this manner.
Xbox: Not just for Halo anymore The original Xbox was basically a PC, with an Intel Celeron CPU. The Xbox 360 is PPC based. Linux will run on both versions of the Xbox, although it is better supported on the Intel version. xbox linux.org has information about the original Linux Xbox port Why use Linux on an Xbox? It's just a PC with TV output! You can convert an Xbox into a DVR, a web/email unit, or an arcade (MAME) gamestation. Free60.org is the home of the project for Linux on the 360, and they have recently posted a working X driver.
Playstation 3: Linux Friendly The Playstation 3 has a Cell CPU (PowerPC based) and a built in hard drive. Sony's default OS has an option to boot into a different OS, designed specifically for Linux Fedora Core will run on the PS3 with some modifications Why run Linux on it? Its one of the first consumer available systems with the Cell microprocessor. Sony actually encourages games to be written for Linux/PS3!
GameCube: Hacking Nintendo Like most current gaming systems, the Nintendo GameCube has a PPC CPU. Unlike the Playstation 3 or the Xbox 360, the GameCube doesn't have networking built in, so Linux has to be loaded from a memory card. gc linux.org is the homepage for Linux on the GameCube Why run Linux on the GameCube? As a thin client As a multimedia terminal As a tiny PowerPC based server What about the Nintendo Wii? It also uses a PPC CPU, but there is no Linux port for it yet (no one has figured out how to boot it!)
Linksys WRT54G Wireless Routers Linksys released the WRT54G Wireless Router with Linux as its core OS Since that time, some of the models have switched to using VxWorks, but they still sell Linux driven models. The CPU is a Broadcom ARM based processor. Linksys released all of their firmware under the GPL This enabled custom distributions of Linux to be created that were specifically designed to run on the WRT56G
ipod: My apple tastes better with Linux All ipods use an ARM CPU ipod Linux (ipodlinux.org) enables Linux to run on some ipod models Except the ipod Shuffle, which relies solely on an mp3 decoder chip Why? Additional functionality, ogg, video on older models. Rockbox (rockbox.org) also provides a complete open source firmware replacement for ipods and many other audio/video portable devices. Rockbox isn't Linux, they wrote their own mini kernel.
Nokia 880: Tablet PC The Nokia 880 is the newest in Nokia's series of small form factor tablet PCs It uses a TI OMAP ARM CPU. The 880 (like the 700 before it) uses a custom build of Linux. Media Players Web Browser GPS ebooks
IBM Family While many hardware vendors are committed to Linux, IBM has an exceptionally broad range of hardware. All current IBM server classes run Linux and are supported by IBM! IBM servers run on Power (PPC), Cell (PPC) and S390 CPU architectures, in addition to x86 and x86_64.
SGI Itanium Several vendors produce IA64 based systems (Intel, HP), but SGI produces some of the largest NASA has an SGI Altix based Supercomputing cluster (Columbia) with 10,240 IA64 CPUs (20 x 512 CPU units) It runs Linux! SGI's work with the IA64 platform has helped to improve scalability in the Linux 2.6 kernel beyond 1024 CPUs
Sun UltraSPARC T1 In December of 2005, Sun released the UltraSPARC T1 chips (aka Niagara) Designed with 8 cores and 32 threads per socket, the chip performs well on multithreaded integer workloads On March 21, 2006, Sun made the UltraSPARC T1 processor design available under the GNU General Public License via the OpenSPARC project. The published information includes: Verilog source code of the UltraSPARC T1 design; Verification suite and simulation models; ISA specification (UltraSPARC Architecture 2005); Support for Niagara was added to Linux 2.6 in March of 2006
Aurora SPARC Linux A port of Fedora to the SPARC architecture Most 32bit and 64bit SPARC systems are supported Fully supports Sun Niagara systems Not an official Fedora release, yet... Actually older than Fedora! Aurora's first release was a rebuild of Red Hat Linux 7.3
Architecture Support in Fedora In Fedora Core 6, three architectures were supported: x86, x86_64, and ppc While PPC has a userbase, it was by far the smallest of the three. Rather than drop PPC outright, it was decided to come up with a plan for Fedora to empower the community to create and support Secondary Architectures
Disclaimer Many of the details for the Fedora Secondary Architecture plan have not been finalized, or approved by the Fedora Engineering Steering Committee (FESCO) or the Fedora Board. The ideas presented are from early discussions and drafts
A Two Tier System There are two tiers of architectures with Fedora support: Primary Architecture: These are architectures with the majority of the users, the most common architectures. Post F7, these are x86, x86_64. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Secondary Architecture: These are architectures with motivated maintainer teams, and build hardware. Post F7, these are (likely): ppc, sparc, alpha, ia64. Build failures on secondary architectures are not fatal: if packages build for the primary architectures, then they will push to the main repositories. These architectures are secondary only in number of users, not in quality.
Architecture Maintainer Teams Each Secondary Arch will be built and maintained by a team of Architecture Maintainers. Each team will have a lead, who is ultimately responsible for Fedora on that architecture. Each Arch Maintainer Team will be responsible for the following: Receiving notifications of secondary arch build successes and failures Patching packages cleanly such that they build and function correctly on the secondary architecture Notifying package maintainers when changes are made to their packages to support the secondary architecture. Resolving architecture specific bugs filed against packages Holding regular team meetings Meeting target dates for architecture stability, freezes, release candidates, and releases.
Build Environment Secondary Architectures can have buildservers outside of the Red Hat environment. Some Secondary Architectures may leverage Red Hat provided buildsystems, but this is not a requirement, and is not guaranteed. All Package builds will go to the Primary Architecture Builders first Successful builds will then be triggered on all Secondary Architecture Builders Secondary Architecture Builders will report success/failure back to the main Koji infrastructure Builds that fail on the Primary Architecture Builders are not sent to the Secondary Architecture Builders
Community Effort There are already several communities built up around unofficial Fedora ports Alphacore (Fedora on Alpha) Aurora SPARC Linux (Fedora on SPARC) Fedora IA64 The idea is to permit these communities to continue their work officially, as Fedora projects Open doors for new architecture support New architecture designers can create a Fedora port to demonstrate their chip Existing architectures (without Fedora ports) can create one S390 anyone? :)
Consistent Packageset Rather than have each Fedora architecture have a different set of packages, at different version levels, the goal is to enforce a consistent packageset across all Fedora architectures, Primary and Secondary. All packages are generated from the sources and spec files kept in Fedora CVS. Secondary Arch Maintainer teams would get special access to CVS to fix architecture specific bugs, or enable packages to build for their architecture With great power comes great responsibility! Certain packages may be excluded (glibc, kernel) Secondary Architecture specific packages (e.g. Bootloaders) are permitted, but they must live in Fedora CVS and go through the normal package review processes.
Secondary Architecture Milestones Secondary Architectures usually take longer to build than Primary Architectures. Milestones (Freeze Dates, Release Candidate Dates, Release Dates) may be slightly delayed for Secondary Architectures Secondary Architectures are still encouraged to try to meet the Primary Architecture dates, but get an additional buffer period Secondary Architectures that fail to meet major Milestones will be dropped.
Questions?