THE X86_32 WIKI PAGES ARE NO LONGER USED AND ARE OUT OF DATE.
(These wiki pages are being kept for historical reference only.)
Fedora x86 (Intel/AMD/VIA 32 bit)
Contact Info
- IRC: #fedora-x86[?] on freenode.net
- Regular IRC meetings: TBD
- Mailing List:
Introduction
The X86 architecture has been built from the very beginning of Red Hat Linux, but is no longer the primary build target with X86_64 replacing it. This change has happened over the last decade, and the lack of attention by most developers has left the system not as used as before.
This page and targeting is aimed at trying to fix this problem.
Targets
short term goals
- Determine if there are enough active members to be viable.
- Determine which bugs for x86 are outstanding
- Determine what deliverable will be for next release.
- To be decided
long term goals
- Determine which hardware will be supported for release after next.
- To be decided
Accomplished
- To Be Filled out by Team
People
History
The x86 architecture itself has a long and storied history which are better outlined in the IA-32 and X86 Wikipedia articles. Because of the fact that the name of the architecture is confusing with ia64 not being ia32 with a 64 bit bus, and similar items, Fedora has either used i386 or x86 to refer to the architecture.
Supported Hardware
Currently only later models in the i686 architecture are supported:
- Intel: Pentium II and above.
- AMD: ???
- VIA: ???
- DM&P: Vortex86 unsupported
How much of the maintenance problems are due to the PAE feature for supporting more than 4 GiB of physical RAM? How much of the use cases would be affected if PAE were not supported at all, or if more than 4 GiB were tolerated but just unused? What if the limit on supported physical RAM were 8 GiB, or something else towards the low end but still more than 4 GiB?
How much of the maintenance problems are due to supporting more than 2 or 4 CPUs? Hyper-threading?
Running a i686 user-space application under a 64-bit x86_64 kernel is moderately pleasant. The application gets around 3.9GiB of address space, and shared libraries are placed at the high end, just below the stack, and with only 1 page of guard zone between each. This avoids the i686 default fragmentation of putting shared modules at 0x40000000, while increasing the exposure to damage by malware due to predictable layout of address space. Some applications would accept such a tradeoff, particularly in well-managed constrained environments.
Release Notes
Tips
Known Runtime Issues
F25
F26
- BZ#1375732 Anaconda reclaim space is broken on x86
F27
Known build issues
Notes for application developers and package maintainers
Submitting builds
As of 2017-07-12 there should be no need for a maintainer to do a regular build, they are automagically processed through the primary koji.
Packages under review
Get Involved with Fedora x86
Bug Reporting
For general x86-related issues, bugs should be reported against their prospective packages as per standard Fedora process and block the x86 general tracker bug.
Bugs for packages that fail to build should be reported against their prospective packages as per standard Fedora process and block the x86 ExcludeArch tracker bug.