os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Rewrite the platform Tier definitions.

Browse source 
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 2019-11-21 17:38:49 +00:00
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
Show stats Download patch file Download diff file Expand all files Collapse all files

414
en_US.ISO8859-1/articles/committers-guide/article.xml
View file

@ -4002,170 +4002,332 @@ Relnotes: yes</programlisting>
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.</para>
<para>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.</para>
<para>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.</para>
</sect2>
<sect2>
<title>Tier 1: Fully Supported Architectures</title>
<title>Platform Targets</title>
<para>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.</para>
<para>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.</para>
<para>Tier 1 architectures are expected to be Production Quality
with respects to all aspects of the &os; operating system,
including installation and development environments.</para>
<para>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.</para>
<para>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.</para>
<para>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 <quote>native</quote> ABI as
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
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.</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>
<para>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.</para>
</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
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.</para>
<para>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.</para>
<para>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.</para>
<para>The &os; Project provides the following guarantees to
consumers of Tier 1 platforms:</para>
<para>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.</para>
<itemizedlist>
<listitem>
<para>Official &os; release images will be provided by the
release engineering team.</para>
</listitem>
<listitem>
<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;
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.</para>
<para>To maintain maturity of Tier 1 platforms, the &os; Project
will maintain the following resources to support
development:</para>
<para>Current Tier 2 platforms are &arch.arm;, &arch.arm64;,
&arch.mips;, &arch.powerpc;, and &arch.sparc64;.</para>
<itemizedlist>
<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>
<title>Tier 3: Experimental Architectures</title>
<para>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.</para>
<para>Tier 3 platforms have at least partial &os; support. They
are <emphasis>not</emphasis> supported by the security
officer, release engineering, and port management
teams.</para>
<para>Tier 3 platforms may have ports support, either integrated
or external, but do not require it.</para>
<para>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.</para>
<para>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.</para>
<para>Current Tier 3 platforms are &arch.riscv;.</para>
<para>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.</para>
</sect2>
<sect2>
<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>
<para>All systems not otherwise classified into a support tier
are Tier 4 systems.</para>
<para>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.</para>
</sect2>
<sect2>
<title>Policy on Changing the Tier of an Architecture</title>
<para>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.</para>
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.</para>
</sect2>
</sect1>

188
en_US.ISO8859-1/htdocs/platforms/index.xml
View file

@ -13,96 +13,186 @@
<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>
<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>
<tr>
<td>Platform</td>
<td>Mailing List</td>
<td><a href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html">Support Tier</a></td>
<td>Platform Name</td>
<td>TARGET_ARCH</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>
</thead>
<tbody>
<tr>
<td><a href="amd64.html">amd64 (x86-64)</a></td>
<td><a href="mailto:freebsd-amd64@FreeBSD.org">freebsd-amd64@FreeBSD.org</a></td>
<td>64-bit x86</td>
<td><a href="amd64.html">amd64</a></td>
<td>Tier 1</td>
<td>Tier 1</td>
<td>Tier 1</td>
</tr>
<tr>
<td><a href="arm.html">ARM64</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="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>32-bit x86</td>
<td><a href="i386.html">i386</a></td>
<td>Tier 1</td>
<td>Tier 1</td>
<td>Tier 1</td>
</tr>
<tr>
<td><a href="mips.html">MIPS</a></td>
<td><a href="mailto:freebsd-mips@FreeBSD.org">freebsd-mips@FreeBSD.org</a></td>
<td>PC98</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 2</td>
<td>Tier 4 <a href="#n-gcc4">*2</a></td>
</tr>
<tr>
<td><a href="ppc.html">PowerPC (ppc)</a></td>
<td><a href="mailto:freebsd-ppc@FreeBSD.org">freebsd-ppc@FreeBSD.org</a></td>
<td>32-bit MIPS hard-float</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>
</tr>
<tr>
<td>64-bit SPARCv9</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 4 <a href="#n-gcc4">*2</a></td>
</tr>
</tbody>
</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>
<table>
<p>These platforms were supported by older versions of FreeBSD.</p>
<table class="tblbasic">
<thead>
<tr>
<td>Project Page</td>
<td>Mailing List</td>
<td><a href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.html">Support Tier</a></td>
<td>Platform Name</td>
<td>TARGET_ARCH</td>
<td>Last Supported Release</td>
</tr>
</thead>
<tbody>
<tr>
<td><a href="alpha.html">FreeBSD/alpha Project</a></td>
<td><a href="mailto:freebsd-alpha@FreeBSD.org">freebsd-alpha@FreeBSD.org</a></td>
<td>Tier 4 (support discontinued as of 7.0R)</td>
<td>Alpha</td>
<td><a href="alpha.html">alpha</a></td>
<td><a href="&base;/releases/index.html#rel6-4">6.4</a></td>
</tr>
<tr>
<td><a href="ia64/index.html">FreeBSD/ia64 Project</a></td>
<td><a href="mailto:freebsd-ia64@FreeBSD.org">freebsd-ia64@FreeBSD.org</a></td>
<td>Tier 2 through FreeBSD 10. Unsupported after.</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>
<td>Intel IA-64</td>
<td><a href="ia64/index.html">ia64</a></td>
<td><a href="&base;/releases/index.html#rel10-4">10.4</a></td>
</tr>
</tbody>
</table>
<p>For general architecture questions, mail <a href="mailto:freebsd-arch@FreeBSD.org">freebsd-arch@FreeBSD.org</a></p>
</body>
</html>

4
en_US.ISO8859-1/htdocs/releases/index.xml
View file

@ -158,7 +158,7 @@
</em>
</li>
<li><b>10.4</b> (October, 2017)
<li><a name="rel10-4"></a><b>10.4</b> (October, 2017)
<em>
<a href="10.4R/announce.html">Announcement</a>:
<a href="10.4R/relnotes.html">Release Notes</a>:
@ -361,7 +361,7 @@
</em>
</li>
<li><b>6.4</b> (November, 2008)
<li><a name="rel6-4"></a><b>6.4</b> (November, 2008)
<em>
<a href="6.4R/announce.html">Announcement</a>:
<a href="6.4R/relnotes.html">Release Notes</a>: