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

The FreeBSD Core Team has approved a new policy with regards to the

Browse source 
status of various architectural platforms and requirements for
support and development of those platforms.  This policy distinguishes
systems into four tiers:

Tier 1: Fully Supported Architectures
Tier 2: Developmental Architectures
Tier 3: Experimental Architectures
Tier 4: Unsupported Architectures

In addition, the Core Team has also approved a policy regarding how
the status of a hardware architecture may be formally changed.  This
policy is new, and subject to review, comment, and modification as
appropriate.  The details of this policy are implemented in this
change to the FreeBSD Committer's Handbook, which all committers
are encouraged to read and review.

Note: Although sparc64 is currently listed as a 'Developmental
Architecture', it is expected that it will become a 'Fully Supported
Architecture' prior to FreeBSD 5.0.  Likewise, it is likely that
ia64 will become a 'Fully Supported Architecture' prior to the
release.
This commit is contained in:
Robert Watson 2002-10-02 21:16:30 +00:00
parent 611aa86b9d
commit 66f5756a50
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=14461
1 changed files with 146 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

150
en_US.ISO8859-1/articles/committers-guide/article.sgml
View file

@ -579,11 +579,11 @@
</itemizedlist>
<para>You will almost certainly get a conflict because
of the <literal>$Id: article.sgml,v 1.134 2002-09-19 18:32:24 rwatson Exp $</literal> (or in FreeBSD's case,
of the <literal>$Id: article.sgml,v 1.135 2002-10-02 21:16:30 rwatson Exp $</literal> (or in FreeBSD's case,
<literal>$<!-- stop expansion -->FreeBSD<!-- stop expansion -->$</literal>) lines, so you will have to edit
the file to resolve the conflict (remove the marker lines and
the second <literal>$Id: article.sgml,v 1.134 2002-09-19 18:32:24 rwatson Exp $</literal> line, leaving the original
<literal>$Id: article.sgml,v 1.134 2002-09-19 18:32:24 rwatson Exp $</literal> line intact).</para>
the second <literal>$Id: article.sgml,v 1.135 2002-10-02 21:16:30 rwatson Exp $</literal> line, leaving the original
<literal>$Id: article.sgml,v 1.135 2002-10-02 21:16:30 rwatson Exp $</literal> line intact).</para>
</listitem>
<listitem>
@ -1864,7 +1864,8 @@ docs:Documentation Bug:nik:</programlisting>
reference platform is sparc64. Major design work (including
major API and ABI changes) must prove itself on at least one
32 bit and at least one 64 bit platform, preferably the
primary reference platforms.</para>
primary reference platforms, before it may be committed
to the source tree.</para>
</blockquote>
<para>The i386 and sparc64 platforms were chosen due to being more
@ -1883,6 +1884,15 @@ docs:Documentation Bug:nik:</programlisting>
<para>We will continue to re-evaluate this policy as cost and
availability of the 64 bit platforms change.</para>
<para>Developers should also be aware of our Tier Policy for
the long term support of hardware architectures. The rules
here are intended to provide guidance during the development
process, and are distinct from the requirements for features
and architectures listed in that section. The Tier rules for
feature support on architectures at release-time are more
strict than the rules for changes during the development
process.</para>
</sect2>
<sect2>
@ -1941,6 +1951,138 @@ docs:Documentation Bug:nik:</programlisting>
</sect2>
</sect1>
<sect1 id="archs">
<title>Support for Multiple Architectures</title>
<para>FreeBSD is a highly portable operating system intended to
function on many different types of hardware architectures.
Maintaining clean separation of Machine Dependent (MD) and Machine
Independent (MI) code, as well as minimizing MD code is an important
part of our strategy to remain agile with regards to current
hardware trends. Each new hardware architecture supported by
FreeBSD adds substantially to the cost of code maintenance,
toolchain support, and release engineering. It also dramatically
increases the cost of effective testing of kernel changes. As such,
there is strong motivation to differentiate between classes of
support for various architectures while remaining strong in a few
key architectures that are seen as the FreeBSD "target audience".
</para>
<sect2>
<title>Statement of General Intent</title>
<para>The FreeBSD Project targets "production quality commercial
off-the-shelf (COTS) workstation, server, and high-end embedded
systems". By retaining a focus on a narrow set of architectures
of interest in these environments, the FreeBSD Project is able
to maintain high levels of quality, stability, and performance,
as well as minimize the load on various support teams on the
project, such as the ports team, documentation team, as well as
security officer and release engineering teams. Diversity in
hardware support broadens the options for FreeBSD consumers by
offering new features and usage opportunities (such as support
for 64-bit CPUs, use in embedded environments), but these
benfits always be carefully considered in terms of the real-world
maintenance cost associated with additional platform support.
</para>
<para>The FreeBSD 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 under the circumstances required to change the tier
of an architecture.</para>
</sect2>
<sect2>
<title>Tier 1: Fully Supported Architectures</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 inherrently 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 tinderbox support either in the FreeBSD.org cluster, or
easily available for all developers.</para>
<para>Tier 1 architectures are expected to be Production Quality
with respects to all aspects of the FreeBSD operating system,
including installation and development environments.</para>
<para>Current Tier 1 platforms are i386, PC98, and Alpha.</para>
</sect2>
<sect2>
<title>Tier 2: Developmental Architectures</title>
<para>Tier 2 platforms are not supported by the security officer
and release engineering teams. At the discretion of the
toolchain maintainer, they may be supported in the toolchain. New
features added to FreeBSD should be feasible to implement on these
platforms, but an implementation is not required before the
feature may be added to the FreeBSD source tree. The
implementation of a Tier 2 architecture may be committed to the
main FreeBSD tree as long as it does not interefere with
production work on Tier 1 platforms, or substantially with other
Tier 2 platforms. Before a Tier 2 platform can be added to the
FreeBSD base source tree, the platform must be able to boot to at
least single-user mode on real world commodity hardware. Some
exceptions to these rules may be made for new hardware that is
under development by hardware vendors, but not yet available to
the project.</para>
<para>Tier 2 architectures are usually systems targetted 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.</para>
<para>Current Tier 2 platforms are sparc64, PowerPC, and ia64.</para>
</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
maintainer, they may be supported in the toolchain. Tier 3
platforms are architectures for which hardware is not or will not
be available to the project in the forseeable future, for which
there are two or fewer active developers, that can not boot to at
least single-user mode on real hardware (or simulator for new
hardware platforms), or which are considered legacy systems
unlikely to see broad future use. Tier 3 systems will not be
committed to the base source tree, although support for Tier 3
systems may be worked on in the FreeBSD Perforce Repository,
providing source control and easier change integration from the
main FreeBSD tree.</para>
<para>There are currently no Tier 3 platforms.</para>
</sect2>
<sect2>
<title>Tier 4: Unsupported Architectures</title>
<para>Tier 4 systems 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>
</sect2>
<sect2>
<title>Policy on Changing the Tier of an Architecture</title>
<para>Systems may only be moved from one tier to another tier by
approval of the FreeBSD Core Team, which shall make that
decision in collaboration with the Security Officer, Release
Enginering, and toolchain maintenance teams.</para>
</sect2>
</sect1>
<sect1 id="ports">
<title>Ports Specific FAQ</title>