Index: head/en_US.ISO8859-1/articles/committers-guide/article.xml
===================================================================
--- head/en_US.ISO8859-1/articles/committers-guide/article.xml
+++ head/en_US.ISO8859-1/articles/committers-guide/article.xml
@@ -4002,170 +4002,332 @@
documentation team, security officer, and release engineering
teams. Diversity in hardware support broadens the options for
&os; consumers by offering new features and usage
- opportunities (such as support for 64-bit CPUs, use in
- embedded environments, etc.), but these benefits must always
+ opportunities, but these benefits must always
be carefully considered in terms of the real-world maintenance
cost associated with additional platform support.
- The &os; Project differentiates platform targets into
- four tiers. Each tier includes a specification of the
- requirements for an architecture to be in that tier,
- as well as specifying the obligations of developers with
- regards to the platform. In addition, a policy is defined
- regarding the circumstances required to change the tier
- of an architecture.
+ The &os; Project differentiates platform targets into four
+ tiers. Each tier includes a list of guarantees consumers may
+ rely on as well as obligations by the Project and developers
+ to fulfill those guarantees. These lists define the minimum
+ guarantees for each tier. The Project and developers may
+ provide additional levels of support beyond the minimum
+ guarantees for a given tier, but such additional support is
+ not guaranteed. Each platform target is assigned to a
+ specific tier for each stable branch. As a result, a platform
+ target might be assigned to different tiers on concurrent
+ stable branches.
- Tier 1: Fully Supported Architectures
+ Platform Targets
- Tier 1 platforms are fully supported by the security
- officer, release engineering, and toolchain maintenance staff.
- New features added to the operating system must be fully
- functional across all Tier 1 architectures for every release
- (features which are inherently architecture-specific, such as
- support for hardware device drivers, may be exempt from this
- requirement). In general, all Tier 1 platforms must have
- build and test automation support either in the FreeBSD.org
- cluster, or easily available for all developers. Embedded
- platforms may substitute an emulator available in the
- FreeBSD.org cluster for actual hardware.
+ Support for a hardware platform consists of two
+ components: kernel support and userland Application Binary
+ Interfaces (ABIs). Kernel platform support includes things
+ needed to run a &os; kernel on a hardware platform such as
+ machine-dependent virtual memory management and device
+ drivers. A userland ABI specifies an interface for user
+ processes to interact with a &os; kernel and base system
+ libraries. A userland ABI includes system call interfaces,
+ the layout and semantics of public data structures, and the
+ layout and semantics of arguments passed to subroutines. Some
+ components of an ABI may be defined by specifications such as
+ the layout of C++ exception objects or calling conventions for
+ C functions.
- Tier 1 architectures are expected to be Production Quality
- with respects to all aspects of the &os; operating system,
- including installation and development environments.
+ A &os; kernel also uses an ABI (sometimes referred to as
+ the Kernel Binary Interface (KBI)) which includes the
+ semantics and layouts of public data structures and the layout
+ and semantics of arguments to public functions within the
+ kernel itself.
- Tier 1 architectures are expected to be completely
- integrated into the source tree and have all features
- necessary to produce an entire system relevant for that target
- architecture. Tier 1 architectures generally have at least 6
- active developers.
+ A &os; kernel may support multiple userland ABIs. For
+ example, &os;'s amd64 kernel supports &os; amd64 and i386
+ userland ABIs as well as Linux x86_64 and i386 userland ABIs.
+ A &os; kernel should support a native
ABI as
+ the default ABI. The native ABI
generally
+ shares certain properties with the kernel ABI such as the C
+ calling convention, sizes of basic types, etc.
- Tier 1 architectures are expected to be fully supported by
- the ports system. All the ports should build on a Tier 1
- platform, or have the appropriate filters to prevent the
- inappropriate ones from building there. The packaging system
- must support all Tier 1 architectures. To ensure an
- architecture's Tier 1 status, proponents of that architecture
- must show that all relevant packages can be built on that
- platform.
+ Tiers are defined for both kernels and userland ABIs. In
+ the common case, a platform's kernel and &os; ABIs are
+ assigned to the same tier.
+
- Tier 1 embedded architectures must be able to cross-build
- packages on at least one other Tier 1 architecture. The
- packages must be the most relevant for the platform, but may
- be a non-empty subset of those that build natively.
+
+ Tier 1: Fully-Supported Architectures
- Tier 1 architectures must be fully documented. All basic
- operations need to be covered by the handbook or other
- documents. All relevant integration documentation must also
- be integrated into the tree, or readily available.
+ Tier 1 platforms are the most mature &os; platforms.
+ They are supported by the security officer, release
+ engineering, and port management teams. Tier 1 architectures
+ are expected to be Production Quality with respect to all
+ aspects of the &os; operating system, including installation
+ and development environments.
- Current Tier 1 platforms are &arch.i386; and
- &arch.amd64;.
+ The &os; Project provides the following guarantees to
+ consumers of Tier 1 platforms:
+
+
+
+ Official &os; release images will be provided by the
+ release engineering team.
+
+
+ Binary updates and source patches for Security
+ Advisories and Errata Notices will be provided for
+ supported releases.
+
+
+ Source patches for Security Advisories will be
+ provided for supported branches.
+
+
+ Binary updates and source patches for cross-platform
+ Security Advisories will typically be provided at the time
+ of the announcement.
+
+
+ Changes to userland ABIs will generally include
+ compatibility shims to ensure correct operation of
+ binaries compiled against any stable branch where the
+ platform is Tier 1. These shims might not be enabled in
+ the default install. If compatibility shims are not
+ provided for an ABI change, the lack of shims will be
+ clearly documented in the release notes.
+
+
+ Changes to certain portions of the kernel ABI will
+ include compatibility shims to ensure correct operation of
+ kernel modules compiled against the oldest supported
+ release on the branch. Note that not all parts of the
+ kernel ABI are protected.
+
+
+ Official binary packages for third party software will
+ be provided by the ports team. For embedded
+ architectures, these packages may be cross-built from a
+ different architecture.
+
+
+ Most relevant ports should either build or have the
+ appropriate filters to prevent inappropriate ones from
+ building.
+
+
+ New features which are not inherently
+ platform-specific will be fully functional on all Tier 1
+ architectures.
+
+
+ Features and compatibility shims used by binaries
+ compiled against older stable branches may be removed in
+ newer major versions. Such removals will be clearly
+ documented in the release notes.
+
+
+ Tier 1 platforms should be fully documented. Basic
+ operations will be documented in the &os; Handbook.
+
+
+ Tier 1 platforms will be included in the source
+ tree.
+
+
+ Tier 1 platforms should be self-hosting either via the
+ in-tree toolchain or an external toolchain. If an
+ external toolchain is required, official binary packages
+ for an external toolchain will be provided.
+
+
+
+ To maintain maturity of Tier 1 platforms, the &os; Project
+ will maintain the following resources to support
+ development:
+
+
+
+ Build and test automation support either in the
+ FreeBSD.org cluster or some other location easily
+ available for all developers. Embedded platforms may
+ substitute an emulator available in the FreeBSD.org
+ cluster for actual hardware.
+
+
+ Inclusion in the make universe
+ and make tinderbox targets.
+
+
+ Dedicated hardware in one of the &os; clusters for
+ package building (either natively or via
+ qemu-user).
+
+
+
+ Collectively, developers are required to provide the
+ following to maintain the Tier 1 status of a platform:
+
+
+
+ Changes to the source tree should not knowingly break
+ the build of a Tier 1 platform.
+
+
+ Tier 1 architectures must have a mature, healthy
+ ecosystem of users and active developers.
+
+
+ Developers should be able to build packages on
+ commonly available, non-embedded Tier 1 systems. This can
+ mean either native builds if non-embedded systems are
+ commonly available for the platform in question, or it can
+ mean cross-builds hosted on some other Tier 1
+ architecture.
+
+
+ Changes cannot break the userland ABI. If an ABI
+ change is required, ABI compatibility for existing
+ binaries should be provided via use of symbol versioning
+ or shared library version bumps.
+
+
+ Changes merged to stable branches cannot break the
+ protected portions of the kernel ABI. If a kernel ABI
+ change is required, the change should be modified to
+ preserve functionality of existing kernel modules.
+
+
- Tier 2: Developmental Architectures
+ Tier 2: Developmental and Niche Architectures
- Tier 2 platforms are not supported by the security officer
- and release engineering teams. Platform maintainers are
- responsible for toolchain support in the tree. The toolchain
- maintainers are expected to work with the platform maintainers
- to refine these changes. Major new toolchain components are
- allowed to break support for Tier 2 architectures if the
- &os;-local changes have not been incorporated upstream.
- The toolchain maintainers are expected to provide prompt
- review of any proposed changes and cannot block, through their
- inaction, changes going into the tree. New features added to
- &os; should be feasible to implement on these platforms,
- but an implementation is not required before the feature may
- be added to the &os; source tree. New features that may be
- difficult to implement on Tier 2 architectures should provide
- a means of disabling them on those architectures. The
- implementation of a Tier 2 architecture may be committed to
- the main &os; tree as long as it does not interfere with
- production work on Tier 1 platforms, or substantially with
- other Tier 2 platforms. Before a Tier 2 platform can be added
- to the &os; base source tree, the platform must be able to
- boot multi-user on actual hardware. Generally, there must be
- at least three active developers working on the
- platform.
+ Tier 2 platforms are functional, but less mature &os;
+ platforms. They are not supported by the security officer,
+ release engineering, and port management teams.
- Tier 2 architectures are usually systems targeted at Tier
- 1 support, but that are still under development.
- Architectures reaching end of life may also be moved from Tier
- 1 status to Tier 2 status as the availability of resources to
- continue to maintain the system in a Production Quality state
- diminishes. Well supported niche architectures may also be
- Tier 2.
+ Tier 2 platforms may be Tier 1 platform candidates that
+ are still under active development. Architectures reaching
+ end of life may also be moved from Tier 1 status to Tier 2
+ status as the availability of resources to continue to
+ maintain the system in a Production Quality state diminishes.
+ Well-supported niche architectures may also be Tier 2.
- Tier 2 architectures have basic support for them
- integrated into the ports infrastructure. They may have cross
- compilation support added, at the discretion of portmgr. Some
- ports must built natively into packages if the package system
- supports that architecture. If not integrated into the base
- system, some external patches for the architecture for ports
- must be available.
+ The &os; Project provides the following guarantees to
+ consumers of Tier 2 platforms:
- Tier 2 architectures can be integrated into the &os;
- handbook. The basics for how to get a system running must be
- documented, although not necessarily for every single board or
- system a Tier 2 architecture supports. The supported hardware
- list must exist and be relatively recent. It should be
- integrated into the &os; documentation.
+
+
+ The ports infrastructure should include basic support
+ for Tier 2 architectures sufficient to support building
+ ports and packages. This includes support for basic
+ packages such as ports-mgmt/pkg, but there is no guarantee
+ that arbitrary ports will be buildable or
+ functional.
+
+
+ New features which are not inherently
+ platform-specific should be feasible on all Tier 2
+ architectures if not implemented.
+
+
+ Tier 2 platforms will be included in the source
+ tree.
+
+
+ Tier 2 platforms should be self-hosting either via the
+ in-tree toolchain or an external toolchain. If an
+ external toolchain is required, official binary packages
+ for an external toolchain will be provided.
+
+
+ Tier 2 platforms should provide functional kernels and
+ userlands even if an official release distribution is not
+ provided.
+
+
- Current Tier 2 platforms are &arch.arm;, &arch.arm64;,
- &arch.mips;, &arch.powerpc;, and &arch.sparc64;.
+ To maintain maturity of Tier 2 platforms, the &os; Project
+ will maintain the following resources to support
+ development:
+
+
+
+ Inclusion in the make universe
+ and make tinderbox targets.
+
+
+
+ Collectively, developers are required to provide the
+ following to maintain the Tier 2 status of a platform:
+
+
+
+ Changes to the source tree should not knowingly break
+ the build of a Tier 2 platform.
+
+
+ Tier 2 architectures must have an active ecosystem of
+ users and developers.
+
+
+ While changes are permitted to break the userland ABI,
+ the ABI should not be broken gratuitously. Significant
+ userland ABI changes should be restricted to major
+ versions.
+
+
+ New features that are not yet implemented on Tier 2
+ architectures should provide a means of disabling them on
+ those architectures.
+
+
Tier 3: Experimental Architectures
- Tier 3 platforms are not supported by the security officer
- and release engineering teams. At the discretion of the
- toolchain maintainers, they may be supported in the toolchain.
- Tier 3 platforms are architectures in the early stages of
- development, for non-mainstream hardware platforms, or which
- are considered legacy systems unlikely to see broad future
- use. Initial support for Tier 3 platforms is worked on
- in external SCM repositories.
- The transition to &os;'s subversion takes place after
- the platform boots multi-user on hardware; sharing via
- subversion is needed for wider exposure; and multiple
- developers are actively working on the platform.
- Platforms that transition to Tier 3 status may be
- removed from the tree if they are no longer actively supported
- by the &os; developer community at the discretion of the
- release engineer.
+ Tier 3 platforms have at least partial &os; support. They
+ are not supported by the security
+ officer, release engineering, and port management
+ teams.
- Tier 3 platforms may have ports support, either integrated
- or external, but do not require it.
+ Tier 3 platforms are architectures in the early stages of
+ development, for non-mainstream hardware platforms, or which
+ are considered legacy systems unlikely to see broad future
+ use. Initial support for Tier 3 platforms may exist in a
+ separate repository rather than the main source
+ repository.
- Tier 3 platforms must have the basics documented for how
- to build a kernel and how to boot it on at least one target
- hardware or emulation environment. This documentation need
- not be integrated into the &os; tree.
-
- Current Tier 3 platforms are &arch.riscv;.
+ The &os; Project provides no guarantees to consumers of
+ Tier 3 platforms and is not committed to maintaining resources
+ to support development. Tier 3 platforms may not always be
+ buildable, nor are any kernel or userland ABIs considered
+ stable.
Tier 4: Unsupported Architectures
- Tier 4 systems are not supported in any form by the
+ Tier 4 platforms are not supported in any form by the
project.
- All systems not otherwise classified into a support tier
- are Tier 4 systems.
+ All systems not otherwise classified are Tier 4 systems.
+ When a platform transitions to Tier 4, all support for the
+ platform is removed from the source and ports trees. Note
+ that ports support should remain as long as the platform is
+ supported in a branch supported by ports.
Policy on Changing the Tier of an Architecture
Systems may only be moved from one tier to another by
- approval of the &os; Core Team, which shall make that
- decision in collaboration with the Security Officer, Release
- Engineering, and toolchain maintenance teams.
+ approval of the &os; Core Team, which shall make that decision
+ in collaboration with the Security Officer, Release
+ Engineering, and ports management teams. For a platform to be
+ promoted to a higher tier, any missing support guarantees must
+ be satisfied before the promotion is completed.
Index: head/en_US.ISO8859-1/htdocs/platforms/index.xml
===================================================================
--- head/en_US.ISO8859-1/htdocs/platforms/index.xml
+++ head/en_US.ISO8859-1/htdocs/platforms/index.xml
@@ -13,96 +13,186 @@
- If you have comments about a port, or wish to provide feedback to
- the developers, send it to the relevant mailing list.
-
Supported Platforms
- Here is a list of platforms that FreeBSD currently supports.
+ Here is a list of platforms supported by FreeBSD.
-
+
+ Notes
+
+ - armv7 platforms were supported by
+ armv6 prior to 12.0.
+ - These platforms will be transitioned to
+ Tier 4 for 13.0 unless their default toolchain is changed away
+ from GCC 4.2.1.
+
+
Unsupported Platforms
-
+ These platforms were supported by older versions of FreeBSD.
+
+
-
- For general architecture questions, mail freebsd-arch@FreeBSD.org