Rewrite the platform Tier definitions.
Rewrite the prose description of Tiers to be structured as bullet lists of guarantees to users from the Project, guarantees to developers from the Project, and obligations on developers. This includes definitions of userland and kernel ABIs as well as documenting our current practice of ABI stability. The committments for ports are still vague and will require further refinement. Move the Tier status of architectures out of the committers guide and into a table on the platforms page the website listing the Tier for each architecture across currently supported stable branches as well as the projected Tiers for the next stable branch (in this case, 13.x). The table also lists individual TARGET_ARCH values to permit more granularity in Tier definitions (e.g. hard-float vs soft-float). Update the Unsupported Platforms table to only list removed architectures and include the last supported release of these architectures. This required adding anchors for relevant releases on the releases page. Reviewed by: bcr Discussed with: developers@ Differential Revision: https://reviews.freebsd.org/D22439
This commit is contained in:
John Baldwin
parent
a29c43d60a
commit
2df62d170d
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=53619
3 changed files with 429 additions and 177 deletions
|
|
@ -4002,170 +4002,332 @@ Relnotes: yes</programlisting>
|
||||||
documentation team, security officer, and release engineering
|
documentation team, security officer, and release engineering
|
||||||
teams. Diversity in hardware support broadens the options for
|
teams. Diversity in hardware support broadens the options for
|
||||||
&os; consumers by offering new features and usage
|
&os; consumers by offering new features and usage
|
||||||
opportunities (such as support for 64-bit CPUs, use in
|
opportunities, but these benefits must always
|
||||||
embedded environments, etc.), but these benefits must always
|
|
||||||
be carefully considered in terms of the real-world maintenance
|
be carefully considered in terms of the real-world maintenance
|
||||||
cost associated with additional platform support.</para>
|
cost associated with additional platform support.</para>
|
||||||
|
|
||||||
<para>The &os; Project differentiates platform targets into
|
<para>The &os; Project differentiates platform targets into four
|
||||||
four tiers. Each tier includes a specification of the
|
tiers. Each tier includes a list of guarantees consumers may
|
||||||
requirements for an architecture to be in that tier,
|
rely on as well as obligations by the Project and developers
|
||||||
as well as specifying the obligations of developers with
|
to fulfill those guarantees. These lists define the minimum
|
||||||
regards to the platform. In addition, a policy is defined
|
guarantees for each tier. The Project and developers may
|
||||||
regarding the circumstances required to change the tier
|
provide additional levels of support beyond the minimum
|
||||||
of an architecture.</para>
|
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.</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Tier 1: Fully Supported Architectures</title>
|
<title>Platform Targets</title>
|
||||||
|
|
||||||
<para>Tier 1 platforms are fully supported by the security
|
<para>Support for a hardware platform consists of two
|
||||||
officer, release engineering, and toolchain maintenance staff.
|
components: kernel support and userland Application Binary
|
||||||
New features added to the operating system must be fully
|
Interfaces (ABIs). Kernel platform support includes things
|
||||||
functional across all Tier 1 architectures for every release
|
needed to run a &os; kernel on a hardware platform such as
|
||||||
(features which are inherently architecture-specific, such as
|
machine-dependent virtual memory management and device
|
||||||
support for hardware device drivers, may be exempt from this
|
drivers. A userland ABI specifies an interface for user
|
||||||
requirement). In general, all Tier 1 platforms must have
|
processes to interact with a &os; kernel and base system
|
||||||
build and test automation support either in the FreeBSD.org
|
libraries. A userland ABI includes system call interfaces,
|
||||||
cluster, or easily available for all developers. Embedded
|
the layout and semantics of public data structures, and the
|
||||||
platforms may substitute an emulator available in the
|
layout and semantics of arguments passed to subroutines. Some
|
||||||
FreeBSD.org cluster for actual hardware.</para>
|
components of an ABI may be defined by specifications such as
|
||||||
|
the layout of C++ exception objects or calling conventions for
|
||||||
|
C functions.</para>
|
||||||
|
|
||||||
<para>Tier 1 architectures are expected to be Production Quality
|
<para>A &os; kernel also uses an ABI (sometimes referred to as
|
||||||
with respects to all aspects of the &os; operating system,
|
the Kernel Binary Interface (KBI)) which includes the
|
||||||
including installation and development environments.</para>
|
semantics and layouts of public data structures and the layout
|
||||||
|
and semantics of arguments to public functions within the
|
||||||
|
kernel itself.</para>
|
||||||
|
|
||||||
<para>Tier 1 architectures are expected to be completely
|
<para>A &os; kernel may support multiple userland ABIs. For
|
||||||
integrated into the source tree and have all features
|
example, &os;'s amd64 kernel supports &os; amd64 and i386
|
||||||
necessary to produce an entire system relevant for that target
|
userland ABIs as well as Linux x86_64 and i386 userland ABIs.
|
||||||
architecture. Tier 1 architectures generally have at least 6
|
A &os; kernel should support a <quote>native</quote> ABI as
|
||||||
active developers.</para>
|
the default ABI. The native <quote>ABI</quote> generally
|
||||||
|
shares certain properties with the kernel ABI such as the C
|
||||||
|
calling convention, sizes of basic types, etc.</para>
|
||||||
|
|
||||||
<para>Tier 1 architectures are expected to be fully supported by
|
<para>Tiers are defined for both kernels and userland ABIs. In
|
||||||
the ports system. All the ports should build on a Tier 1
|
the common case, a platform's kernel and &os; ABIs are
|
||||||
platform, or have the appropriate filters to prevent the
|
assigned to the same tier.</para>
|
||||||
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.</para>
|
|
||||||
|
|
||||||
<para>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.</para>
|
|
||||||
|
|
||||||
<para>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.</para>
|
|
||||||
|
|
||||||
<para>Current Tier 1 platforms are &arch.i386; and
|
|
||||||
&arch.amd64;.</para>
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Tier 2: Developmental Architectures</title>
|
<title>Tier 1: Fully-Supported Architectures</title>
|
||||||
|
|
||||||
<para>Tier 2 platforms are not supported by the security officer
|
<para>Tier 1 platforms are the most mature &os; platforms.
|
||||||
and release engineering teams. Platform maintainers are
|
They are supported by the security officer, release
|
||||||
responsible for toolchain support in the tree. The toolchain
|
engineering, and port management teams. Tier 1 architectures
|
||||||
maintainers are expected to work with the platform maintainers
|
are expected to be Production Quality with respect to all
|
||||||
to refine these changes. Major new toolchain components are
|
aspects of the &os; operating system, including installation
|
||||||
allowed to break support for Tier 2 architectures if the
|
and development environments.</para>
|
||||||
&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.</para>
|
|
||||||
|
|
||||||
<para>Tier 2 architectures are usually systems targeted at Tier
|
<para>The &os; Project provides the following guarantees to
|
||||||
1 support, but that are still under development.
|
consumers of Tier 1 platforms:</para>
|
||||||
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.</para>
|
|
||||||
|
|
||||||
<para>Tier 2 architectures have basic support for them
|
<itemizedlist>
|
||||||
integrated into the ports infrastructure. They may have cross
|
<listitem>
|
||||||
compilation support added, at the discretion of portmgr. Some
|
<para>Official &os; release images will be provided by the
|
||||||
ports must built natively into packages if the package system
|
release engineering team.</para>
|
||||||
supports that architecture. If not integrated into the base
|
</listitem>
|
||||||
system, some external patches for the architecture for ports
|
<listitem>
|
||||||
must be available.</para>
|
<para>Binary updates and source patches for Security
|
||||||
|
Advisories and Errata Notices will be provided for
|
||||||
|
supported releases.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Source patches for Security Advisories will be
|
||||||
|
provided for supported branches.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Binary updates and source patches for cross-platform
|
||||||
|
Security Advisories will typically be provided at the time
|
||||||
|
of the announcement.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Most relevant ports should either build or have the
|
||||||
|
appropriate filters to prevent inappropriate ones from
|
||||||
|
building.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>New features which are not inherently
|
||||||
|
platform-specific will be fully functional on all Tier 1
|
||||||
|
architectures.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Tier 1 platforms should be fully documented. Basic
|
||||||
|
operations will be documented in the &os; Handbook.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Tier 1 platforms will be included in the source
|
||||||
|
tree.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
|
||||||
<para>Tier 2 architectures can be integrated into the &os;
|
<para>To maintain maturity of Tier 1 platforms, the &os; Project
|
||||||
handbook. The basics for how to get a system running must be
|
will maintain the following resources to support
|
||||||
documented, although not necessarily for every single board or
|
development:</para>
|
||||||
system a Tier 2 architecture supports. The supported hardware
|
|
||||||
list must exist and be relatively recent. It should be
|
|
||||||
integrated into the &os; documentation.</para>
|
|
||||||
|
|
||||||
<para>Current Tier 2 platforms are &arch.arm;, &arch.arm64;,
|
<itemizedlist>
|
||||||
&arch.mips;, &arch.powerpc;, and &arch.sparc64;.</para>
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Inclusion in the <userinput>make universe</userinput>
|
||||||
|
and <userinput>make tinderbox</userinput> targets.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Dedicated hardware in one of the &os; clusters for
|
||||||
|
package building (either natively or via
|
||||||
|
qemu-user).</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
|
||||||
|
<para>Collectively, developers are required to provide the
|
||||||
|
following to maintain the Tier 1 status of a platform:</para>
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>Changes to the source tree should not knowingly break
|
||||||
|
the build of a Tier 1 platform.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Tier 1 architectures must have a mature, healthy
|
||||||
|
ecosystem of users and active developers.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</sect2>
|
||||||
|
|
||||||
|
<sect2>
|
||||||
|
<title>Tier 2: Developmental and Niche Architectures</title>
|
||||||
|
|
||||||
|
<para>Tier 2 platforms are functional, but less mature &os;
|
||||||
|
platforms. They are not supported by the security officer,
|
||||||
|
release engineering, and port management teams.</para>
|
||||||
|
|
||||||
|
<para>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.</para>
|
||||||
|
|
||||||
|
<para>The &os; Project provides the following guarantees to
|
||||||
|
consumers of Tier 2 platforms:</para>
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>New features which are not inherently
|
||||||
|
platform-specific should be feasible on all Tier 2
|
||||||
|
architectures if not implemented.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Tier 2 platforms will be included in the source
|
||||||
|
tree.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Tier 2 platforms should provide functional kernels and
|
||||||
|
userlands even if an official release distribution is not
|
||||||
|
provided.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
|
||||||
|
<para>To maintain maturity of Tier 2 platforms, the &os; Project
|
||||||
|
will maintain the following resources to support
|
||||||
|
development:</para>
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>Inclusion in the <userinput>make universe</userinput>
|
||||||
|
and <userinput>make tinderbox</userinput> targets.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
|
||||||
|
<para>Collectively, developers are required to provide the
|
||||||
|
following to maintain the Tier 2 status of a platform:</para>
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>Changes to the source tree should not knowingly break
|
||||||
|
the build of a Tier 2 platform.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Tier 2 architectures must have an active ecosystem of
|
||||||
|
users and developers.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>New features that are not yet implemented on Tier 2
|
||||||
|
architectures should provide a means of disabling them on
|
||||||
|
those architectures.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Tier 3: Experimental Architectures</title>
|
<title>Tier 3: Experimental Architectures</title>
|
||||||
|
|
||||||
<para>Tier 3 platforms are not supported by the security officer
|
<para>Tier 3 platforms have at least partial &os; support. They
|
||||||
and release engineering teams. At the discretion of the
|
are <emphasis>not</emphasis> supported by the security
|
||||||
toolchain maintainers, they may be supported in the toolchain.
|
officer, release engineering, and port management
|
||||||
Tier 3 platforms are architectures in the early stages of
|
teams.</para>
|
||||||
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.</para>
|
|
||||||
|
|
||||||
<para>Tier 3 platforms may have ports support, either integrated
|
<para>Tier 3 platforms are architectures in the early stages of
|
||||||
or external, but do not require it.</para>
|
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.</para>
|
||||||
|
|
||||||
<para>Tier 3 platforms must have the basics documented for how
|
<para>The &os; Project provides no guarantees to consumers of
|
||||||
to build a kernel and how to boot it on at least one target
|
Tier 3 platforms and is not committed to maintaining resources
|
||||||
hardware or emulation environment. This documentation need
|
to support development. Tier 3 platforms may not always be
|
||||||
not be integrated into the &os; tree.</para>
|
buildable, nor are any kernel or userland ABIs considered
|
||||||
|
stable.</para>
|
||||||
<para>Current Tier 3 platforms are &arch.riscv;.</para>
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Tier 4: Unsupported Architectures</title>
|
<title>Tier 4: Unsupported Architectures</title>
|
||||||
|
|
||||||
<para>Tier 4 systems are not supported in any form by the
|
<para>Tier 4 platforms are not supported in any form by the
|
||||||
project.</para>
|
project.</para>
|
||||||
|
|
||||||
<para>All systems not otherwise classified into a support tier
|
<para>All systems not otherwise classified are Tier 4 systems.
|
||||||
are Tier 4 systems.</para>
|
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.</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Policy on Changing the Tier of an Architecture</title>
|
<title>Policy on Changing the Tier of an Architecture</title>
|
||||||
|
|
||||||
<para>Systems may only be moved from one tier to another by
|
<para>Systems may only be moved from one tier to another by
|
||||||
approval of the &os; Core Team, which shall make that
|
approval of the &os; Core Team, which shall make that decision
|
||||||
decision in collaboration with the Security Officer, Release
|
in collaboration with the Security Officer, Release
|
||||||
Engineering, and toolchain maintenance teams.</para>
|
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.</para>
|
||||||
</sect2>
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -13,96 +13,186 @@
|
||||||
|
|
||||||
<body class="navinclude.developers">
|
<body class="navinclude.developers">
|
||||||
|
|
||||||
<p>If you have comments about a port, or wish to provide feedback to
|
|
||||||
the developers, send it to the relevant mailing list.</p>
|
|
||||||
|
|
||||||
<h2>Supported Platforms</h2>
|
<h2>Supported Platforms</h2>
|
||||||
|
|
||||||
<p>Here is a list of platforms that FreeBSD currently supports.</p>
|
<p>Here is a list of platforms supported by FreeBSD.</p>
|
||||||
|
|
||||||
<table>
|
<table class="tblbasic">
|
||||||
<thead>
|
<thead>
|
||||||
<tr>
|
<tr>
|
||||||
<td>Platform</td>
|
<td>Platform Name</td>
|
||||||
<td>Mailing List</td>
|
<td>TARGET_ARCH</td>
|
||||||
<td><a href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html">Support Tier</a></td>
|
<td>11.x <a href="&base;/doc/en_US.ISO8859-1/articles/committers-guide/archs.html">Support Tier</a></td>
|
||||||
|
<td>12.x <a href="&base;/doc/en_US.ISO8859-1/articles/committers-guide/archs.html">Support Tier</a></td>
|
||||||
|
<td>Projected 13.x <a href="&base;/doc/en_US.ISO8859-1/articles/committers-guide/archs.html">Support Tier</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
</thead>
|
</thead>
|
||||||
|
|
||||||
<tbody>
|
<tbody>
|
||||||
<tr>
|
<tr>
|
||||||
<td><a href="amd64.html">amd64 (x86-64)</a></td>
|
<td>64-bit x86</td>
|
||||||
<td><a href="mailto:freebsd-amd64@FreeBSD.org">freebsd-amd64@FreeBSD.org</a></td>
|
<td><a href="amd64.html">amd64</a></td>
|
||||||
|
<td>Tier 1</td>
|
||||||
|
<td>Tier 1</td>
|
||||||
<td>Tier 1</td>
|
<td>Tier 1</td>
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td><a href="arm.html">ARM64</a></td>
|
<td>32-bit x86</td>
|
||||||
<td><a href="mailto:freebsd-arm@FreeBSD.org">freebsd-arm@FreeBSD.org</a></td>
|
<td><a href="i386.html">i386</a></td>
|
||||||
<td>Tier 2</td>
|
<td>Tier 1</td>
|
||||||
</tr>
|
<td>Tier 1</td>
|
||||||
<tr>
|
|
||||||
<td><a href="arm.html">ARM</a></td>
|
|
||||||
<td><a href="mailto:freebsd-arm@FreeBSD.org">freebsd-arm@FreeBSD.org</a></td>
|
|
||||||
<td>Tier 2</td>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td><a href="i386.html">i386 (IA-32)</a></td>
|
|
||||||
<td><a href="mailto:freebsd-current@FreeBSD.org">freebsd-current@FreeBSD.org</a></td>
|
|
||||||
<td>Tier 1</td>
|
<td>Tier 1</td>
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td><a href="mips.html">MIPS</a></td>
|
<td>PC98</td>
|
||||||
<td><a href="mailto:freebsd-mips@FreeBSD.org">freebsd-mips@FreeBSD.org</a></td>
|
<td><a href="pc98.html">pc98</a></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4</td>
|
||||||
|
<td>Tier 4</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>64-bit ARMv8</td>
|
||||||
|
<td><a href="arm.html">aarch64</a></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>32-bit ARMv4/5</td>
|
||||||
|
<td><a href="arm.html">arm</a></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>32-bit big-endian ARM</td>
|
||||||
|
<td><a href="arm.html">armeb</a></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4</td>
|
||||||
|
<td>Tier 4</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>32-bit ARMv6</td>
|
||||||
|
<td><a href="arm.html">armv6</a></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>32-bit ARMv7</td>
|
||||||
|
<td><a href="arm.html">armv7</a></td>
|
||||||
|
<td><a href="#n-armv7">*1</a></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>32-bit MIPS soft-float</td>
|
||||||
|
<td><a href="mips.html">mips, mipsel</a></td>
|
||||||
<td>Tier 3</td>
|
<td>Tier 3</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4 <a href="#n-gcc4">*2</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td><a href="ppc.html">PowerPC (ppc)</a></td>
|
<td>32-bit MIPS hard-float</td>
|
||||||
<td><a href="mailto:freebsd-ppc@FreeBSD.org">freebsd-ppc@FreeBSD.org</a></td>
|
<td><a href="mips.html">mipshf, mipselhf</a></td>
|
||||||
|
<td></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4 <a href="#n-gcc4">*2</a></td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>32-bit MIPS n32</td>
|
||||||
|
<td><a href="mips.html">mipsn32</a></td>
|
||||||
|
<td>Tier 3</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4 <a href="#n-gcc4">*2</a></td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>64-bit MIPS soft-float</td>
|
||||||
|
<td><a href="mips.html">mips64, mips64el</a></td>
|
||||||
|
<td>Tier 3</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4 <a href="#n-gcc4">*2</a></td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>64-bit MIPS hard-float</td>
|
||||||
|
<td><a href="mips.html">mips64hf, mips64elhf</a></td>
|
||||||
|
<td></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4 <a href="#n-gcc4">*2</a></td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>32-bit PowerPC</td>
|
||||||
|
<td><a href="ppc.html">powerpc</a></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4 <a href="#n-gcc4">*2</a></td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>32-bit PowerPC with SPE</td>
|
||||||
|
<td><a href="ppc.html">powerpcspe</a></td>
|
||||||
|
<td></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4 <a href="#n-gcc4">*2</a></td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>64-bit PowerPC</td>
|
||||||
|
<td><a href="ppc.html">powerpc64</a></td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4 <a href="#n-gcc4">*2</a></td>
|
||||||
|
</tr>
|
||||||
|
<tr>
|
||||||
|
<td>64-bit RISC-V</td>
|
||||||
|
<td><a href="https://wiki.freebsd.org/riscv">riscv64,
|
||||||
|
riscv64sf</a></td>
|
||||||
|
<td></td>
|
||||||
|
<td>Tier 3</td>
|
||||||
<td>Tier 2</td>
|
<td>Tier 2</td>
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
|
<td>64-bit SPARCv9</td>
|
||||||
<td><a href="sparc.html">sparc64</a></td>
|
<td><a href="sparc.html">sparc64</a></td>
|
||||||
<td><a href="mailto:freebsd-sparc@FreeBSD.org">freebsd-sparc@FreeBSD.org</a></td>
|
|
||||||
<td>Tier 2</td>
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 2</td>
|
||||||
|
<td>Tier 4 <a href="#n-gcc4">*2</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
</tbody>
|
</tbody>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
|
<h3>Notes</h3>
|
||||||
|
<ol>
|
||||||
|
<li><a name="n-armv7"></a>armv7 platforms were supported by
|
||||||
|
armv6 prior to 12.0.</li>
|
||||||
|
<li><a name="n-gcc4"></a>These platforms will be transitioned to
|
||||||
|
Tier 4 for 13.0 unless their default toolchain is changed away
|
||||||
|
from GCC 4.2.1.</li>
|
||||||
|
</ol>
|
||||||
|
|
||||||
<h2>Unsupported Platforms</h2>
|
<h2>Unsupported Platforms</h2>
|
||||||
|
|
||||||
<table>
|
<p>These platforms were supported by older versions of FreeBSD.</p>
|
||||||
|
|
||||||
|
<table class="tblbasic">
|
||||||
<thead>
|
<thead>
|
||||||
<tr>
|
<tr>
|
||||||
<td>Project Page</td>
|
<td>Platform Name</td>
|
||||||
<td>Mailing List</td>
|
<td>TARGET_ARCH</td>
|
||||||
<td><a href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html">Support Tier</a></td>
|
<td>Last Supported Release</td>
|
||||||
</tr>
|
</tr>
|
||||||
</thead>
|
</thead>
|
||||||
|
|
||||||
<tbody>
|
<tbody>
|
||||||
<tr>
|
<tr>
|
||||||
<td><a href="alpha.html">FreeBSD/alpha Project</a></td>
|
<td>Alpha</td>
|
||||||
<td><a href="mailto:freebsd-alpha@FreeBSD.org">freebsd-alpha@FreeBSD.org</a></td>
|
<td><a href="alpha.html">alpha</a></td>
|
||||||
<td>Tier 4 (support discontinued as of 7.0R)</td>
|
<td><a href="&base;/releases/index.html#rel6-4">6.4</a></td>
|
||||||
</tr>
|
</tr>
|
||||||
<tr>
|
<tr>
|
||||||
<td><a href="ia64/index.html">FreeBSD/ia64 Project</a></td>
|
<td>Intel IA-64</td>
|
||||||
<td><a href="mailto:freebsd-ia64@FreeBSD.org">freebsd-ia64@FreeBSD.org</a></td>
|
<td><a href="ia64/index.html">ia64</a></td>
|
||||||
<td>Tier 2 through FreeBSD 10. Unsupported after.</td>
|
<td><a href="&base;/releases/index.html#rel10-4">10.4</a></td>
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td><a href="https://wiki.freebsd.org/riscv">FreeBSD/RISC-V Project</a></td>
|
|
||||||
<td><a href="mailto:freebsd-riscv@FreeBSD.org">freebsd-riscv@FreeBSD.org</a></td>
|
|
||||||
<td>Tier 3 beginning in FreeBSD 12</td>
|
|
||||||
</tr>
|
|
||||||
<tr>
|
|
||||||
<td><a href="pc98.html">FreeBSD/pc98 Project</a></td>
|
|
||||||
<td><a href="mailto:re-pc98@FreeBSD.org">re-pc98@FreeBSD.org</a></td>
|
|
||||||
<td>Tier 2 until FreeBSD 11. Unsupported after.</td>
|
|
||||||
</tr>
|
</tr>
|
||||||
</tbody>
|
</tbody>
|
||||||
</table>
|
</table>
|
||||||
|
|
||||||
<p>For general architecture questions, mail <a href="mailto:freebsd-arch@FreeBSD.org">freebsd-arch@FreeBSD.org</a></p>
|
|
||||||
</body>
|
</body>
|
||||||
</html>
|
</html>
|
||||||
|
|
|
||||||
|
|
@ -158,7 +158,7 @@
|
||||||
</em>
|
</em>
|
||||||
</li>
|
</li>
|
||||||
|
|
||||||
<li><b>10.4</b> (October, 2017)
|
<li><a name="rel10-4"></a><b>10.4</b> (October, 2017)
|
||||||
<em>
|
<em>
|
||||||
<a href="10.4R/announce.html">Announcement</a>:
|
<a href="10.4R/announce.html">Announcement</a>:
|
||||||
<a href="10.4R/relnotes.html">Release Notes</a>:
|
<a href="10.4R/relnotes.html">Release Notes</a>:
|
||||||
|
|
@ -361,7 +361,7 @@
|
||||||
</em>
|
</em>
|
||||||
</li>
|
</li>
|
||||||
|
|
||||||
<li><b>6.4</b> (November, 2008)
|
<li><a name="rel6-4"></a><b>6.4</b> (November, 2008)
|
||||||
<em>
|
<em>
|
||||||
<a href="6.4R/announce.html">Announcement</a>:
|
<a href="6.4R/announce.html">Announcement</a>:
|
||||||
<a href="6.4R/relnotes.html">Release Notes</a>:
|
<a href="6.4R/relnotes.html">Release Notes</a>:
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue