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

A new section explaining the policy on encumbered files in the source

Browse source 
tree.  Based on text from phk, and run through the txt2docbook filter.
This commit is contained in:
Nik Clayton 1999-07-07 00:00:18 +00:00
parent b5d23da6da
commit 9cc9facec2
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=5179
4 changed files with 372 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

94
en/handbook/policies/chapter.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$Id: chapter.sgml,v 1.7 1999-03-08 22:04:45 nik Exp $
$Id: chapter.sgml,v 1.8 1999-07-07 00:00:18 nik Exp $
-->
<chapter id="policies">
@ -218,6 +218,98 @@ inclusion in the next vendor release.
obrien@freebsd.org - 30 March 1997</programlisting>
</sect1>
<sect1 id="policies-encumbered">
<title>Encumbered files</title>
<para>It might occasionally be necessary to include an encumbered file in
the FreeBSD source tree. For example, if a device requires a small
piece of binary code to be loaded to it before the device will operate,
and we do not have the source to that code, then the binary file is said
to be encumbered. The following policies apply to including encumbered
files in the FreeBSD source tree.</para>
<orderedlist>
<listitem>
<para>Any file which is interpreted or executed by the system CPU(s)
and not in source format is encumbered.</para>
</listitem>
<listitem>
<para>Any file with a license more restrictive than BSD or GNU is
encumbered.</para>
</listitem>
<listitem>
<para>A file which contains downloadable binary data for use by the
hardware is not encumbered, unless (1) or (2) apply to it. It must
be stored in an architecture neutral ASCII format (file2c or
uuencoding is recommended).</para>
</listitem>
<listitem>
<para>Any encumbered file requires specific approval from the <link
linkend="staff-core">Core team</link> before it is added to the
CVS repository.</para>
</listitem>
<listitem>
<para>Encumbered files go in <filename>src/contrib</filename> or
<filename>src/sys/contrib</filename>.</para>
</listitem>
<listitem>
<para>The entire module should be kept together. There is no point in
splitting it, unless there is code-sharing with non-encumbered
code.</para>
</listitem>
<listitem>
<para>Object files are named
<filename><replaceable>arch</replaceable>/<replaceable>filename</replaceable>.o.uu></filename>.</para>
</listitem>
<listitem>
<para>Kernel files;</para>
<orderedlist>
<listitem>
<para>Should always be referenced in
<filename>conf/files.*</filename> (for build simplicity).</para>
</listitem>
<listitem>
<para>Should always be in <filename>LINT</filename>, but the <link
linkend="staff-core">Core team</link> decides per case if it
should be commented out or not. The <link
linkend="staff-core">Core team</link> can, of course, change
their minds later on.</para>
</listitem>
<listitem>
<para>The <link linkend="staff-who">Release Engineer</link>
decides whether or not it goes in to the release.</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>User-land files;</para>
<orderedlist>
<listitem>
<para>The <link linkend="staff-core">Core team</link> decides if
the code should be part of <command>make world</command>.</para>
</listitem>
<listitem>
<para>The <link linkend="staff-who">Release Engineer</link>
decides if it goes in to the release.</para>
</listitem>
</orderedlist>
</listitem>
</orderedlist>
</sect1>
<sect1 id="policies-shlib">
<title>Shared Libraries</title>