265 lines
11 KiB
Text
265 lines
11 KiB
Text
<!-- $Id: hackers.sgml,v 1.2 1997-11-28 17:29:22 steve Exp $ -->
|
|
<!-- The FreeBSD Documentation Project -->
|
|
|
|
<sect>
|
|
<heading>For serious FreeBSD hackers only<label id="hackers"></heading>
|
|
|
|
<sect1>
|
|
<heading>
|
|
What are SNAPs and RELEASEs?
|
|
</heading>
|
|
|
|
<p>There are currently three active/semi-active branches in the FreeBSD
|
|
<url url="http://www.freebsd.org/cgi/cvsweb.cgi" name="CVS Repository">:
|
|
|
|
<itemize>
|
|
<item><bf/RELENG_2_1_0/ AKA <bf/2.1-stable/ AKA <bf/"2.1 branch"/
|
|
<item><bf/RELENG_2_2/ AKA <bf/2.2-stable/ AKA <bf/"2.2 branch"/
|
|
<item><bf/HEAD/ AKA <bf/-current/ AKA <bf/3.0-current/
|
|
</itemize>
|
|
|
|
<p><bf/HEAD/ is not an actual branch tag, like the other two, it's
|
|
simply a symbolic constant for
|
|
<em/"the current, non-branched development stream"/ which we simply
|
|
refer to as <bf/-current/.
|
|
|
|
<p>Right now, <bf/-current/ is the 3.0 development stream and the
|
|
<bf/2.2-stable/ branch, <bf/RELENG_2_2/, forked off from
|
|
<bf/-current/ in November 1996.
|
|
|
|
<p>The <bf/2.1-stable/ branch, <bf/RELENG_2_1_0/, departed -current in
|
|
September of 1994.
|
|
|
|
<sect1>
|
|
<heading>
|
|
How do I make my own custom release?<label id="custrel">
|
|
</heading>
|
|
|
|
<p>To make a release you need to do three things: First, you need to
|
|
be running a kernel with the <htmlurl
|
|
url="http://www.freebsd.org/cgi/man.cgi?vn" name="vn"> driver configured
|
|
in. Add this to your kernel config file and build a new kernel:
|
|
|
|
<verb>
|
|
pseudo-device vn #Vnode driver (turns a file into a device)
|
|
</verb>
|
|
|
|
<p>Second, you have to have the whole CVS repository at hand.
|
|
To get this you can use <url url="../handbook/cvsup.html" name="CVSUP">
|
|
but in your supfile set the release name to cvs and remove any tag or
|
|
date fields:
|
|
|
|
<verb>
|
|
*default prefix=/home/ncvs
|
|
*default base=/a
|
|
*default host=cvsup.FreeBSD.org
|
|
*default release=cvs
|
|
*default delete compress use-rel-suffix
|
|
|
|
## Main Source Tree
|
|
src-all
|
|
src-eBones
|
|
src-secure
|
|
|
|
# Other stuff
|
|
ports-all
|
|
www
|
|
doc-all
|
|
</verb>
|
|
|
|
<p>Then run <tt/cvsup -g supfile/ to suck all the good bits onto your
|
|
box...
|
|
|
|
<p>Finally, you need a chunk of empty space to build into. Let's
|
|
say it's in <tt>/some/big/filesystem</tt>, and from the example
|
|
above you've got the CVS repository in <tt>/home/ncvs</tt>:
|
|
|
|
<verb>
|
|
setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs
|
|
cd /usr/src/release
|
|
make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release
|
|
</verb>
|
|
|
|
<p>An entire release will be built in
|
|
<tt>/some/big/filesystem/release</tt> and you will have a full FTP-type
|
|
installation in <tt>/some/big/filesystem/release/R/ftp</tt> when you're
|
|
done. If you want to build your SNAP along some other branch than
|
|
-current, you can also add <tt/RELEASETAG=SOMETAG/ to
|
|
the make release command line above, e.g. <tt/RELEASETAG=RELENG_2_2/
|
|
would build an up-to-the- minute 2.2 GAMMA snapshot.
|
|
|
|
<sect1>
|
|
<heading>How do I create customized installation disks?</heading>
|
|
|
|
<p>The entire process of creating installation disks and source and
|
|
binary archives is automated by various targets in
|
|
<tt>/usr/src/release/Makefile</tt>. The information there should
|
|
be enough to get you started. However, it should be said that this
|
|
involves doing a ``make world'' and will therefore take up a lot of
|
|
time and disk space.
|
|
|
|
<sect1>
|
|
<heading>``make world'' clobbers my existing installed binaries.</heading>
|
|
|
|
<p>Yes, this is the general idea; as its name might suggest,
|
|
``make world'' rebuilds every system binary from scratch, so you can be
|
|
certain of having a clean and consistent environment at the end (which
|
|
is why it takes so long).
|
|
|
|
<p>If the environment variable <tt/DESTDIR/ is defined while running
|
|
``<tt/make world/'' or ``<tt/make install/'', the newly-created
|
|
binaries will be deposited in a directory tree identical to the
|
|
installed one, rooted at <tt>${DESTDIR}</tt>.
|
|
Some random combination of shared libraries modifications and
|
|
program rebuilds can cause this to fail in ``<tt/make world/'',
|
|
however.
|
|
|
|
<sect1>
|
|
<heading>
|
|
When my system boots, it says ``(bus speed defaulted)''.
|
|
</heading>
|
|
|
|
<p>The Adaptec 1542 SCSI host adapters allow the user to configure
|
|
their bus access speed in software. Previous versions of the
|
|
1542 driver tried to determine the fastest usable speed and set
|
|
the adapter to that. We found that this breaks some users'
|
|
systems, so you now have to define the ``<tt/TUNE_1542/'' kernel
|
|
configuration option in order to have this take place. Using it
|
|
on those systems where it works may make your disks run faster,
|
|
but on those systems where it doesn't, your data could be
|
|
corrupted.
|
|
|
|
<sect1>
|
|
<heading>
|
|
Can I follow current with limited Internet access?<label id="ctm">
|
|
</heading>
|
|
|
|
<p>Yes, you can do this <tt /without/ downloading the whole source tree
|
|
by using the <url url="../handbook/ctm.html" name="CTM facility.">
|
|
|
|
<sect1>
|
|
<heading>How did you split the distribution into 240k files?</heading>
|
|
|
|
<p>Newer BSD based systems have a ``<tt/-b/'' option to split that
|
|
allows them to split files on arbitrary byte boundaries.
|
|
|
|
<p>Here is an example from <tt>/usr/src/Makefile</tt>.
|
|
|
|
<verb>
|
|
bin-tarball:
|
|
(cd ${DISTDIR}; \
|
|
tar cf - . \
|
|
gzip --no-name -9 -c | \
|
|
split -b 240640 - \
|
|
${RELEASEDIR}/tarballs/bindist/bin_tgz.)
|
|
</verb>
|
|
|
|
<sect1>
|
|
<heading>I've written a kernel extension, who do I send it to?</heading>
|
|
|
|
<p>Please take a look at <url url="../handbook/contrib.html"
|
|
name="The Handbook entry on how to submit code.">
|
|
|
|
<p>And thanks for the thought!
|
|
|
|
<sect1>
|
|
<heading>How are Plug N Play ISA cards detected and initialized?</heading>
|
|
|
|
<p>By: <url url="mailto:uhclem@nemesis.lonestar.org"
|
|
name="Frank Durda IV">
|
|
|
|
<p>In a nutshell, there a few I/O ports that all of the PnP boards
|
|
respond to when the host asks if anyone is out there. So when
|
|
the PnP probe routine starts, he asks if there are any PnP boards
|
|
present, and all the PnP boards respond with their model # to
|
|
a I/O read of the same port, so the probe routine gets a wired-OR
|
|
``yes'' to that question. At least one bit will be on in that
|
|
reply. Then the probe code is able to cause boards with board
|
|
model IDs (assigned by Microsoft/Intel) lower than X to go
|
|
``off-line''. It then looks to see if any boards are still
|
|
responding to the query. If the answer was ``<tt/0/'', then
|
|
there are no boards with IDs above X. Now probe asks if there
|
|
are any boards below ``X''. If so, probe knows there are boards
|
|
with a model numbers below X. Probe then asks for boards greater
|
|
than X-(limit/4) to go off-line. If repeats the query. By
|
|
repeating this semi-binary search of IDs-in-range enough times,
|
|
the probing code will eventually identify all PnP boards present
|
|
in a given machine with a number of iterations that is much lower
|
|
than what 2^64 would take.
|
|
|
|
<p>The IDs are two 32-bit fields (hence 2ˆ64) + 8 bit checksum.
|
|
The first 32 bits are a vendor identifier. They never come out
|
|
and say it, but it appears to be assumed that different types of
|
|
boards from the same vendor could have different 32-bit vendor
|
|
ids. The idea of needing 32 bits just for unique manufacturers
|
|
is a bit excessive.
|
|
|
|
<p>The lower 32 bits are a serial #, ethernet address, something
|
|
that makes this one board unique. The vendor must never produce
|
|
a second board that has the same lower 32 bits unless the upper
|
|
32 bits are also different. So you can have multiple boards of
|
|
the same type in the machine and the full 64 bits will still be
|
|
unique.
|
|
|
|
<p>The 32 bit groups can never be all zero. This allows the
|
|
wired-OR to show non-zero bits during the initial binary search.
|
|
|
|
<p>Once the system has identified all the board IDs present, it will
|
|
reactivate each board, one at a time (via the same I/O ports),
|
|
and find out what resources the given board needs, what interrupt
|
|
choices are available, etc. A scan is made over all the boards
|
|
to collect this information.
|
|
|
|
<p>This info is then combined with info from any ECU files on the
|
|
hard disk or wired into the MLB BIOS. The ECU and BIOS PnP
|
|
support for hardware on the MLB is usually synthetic, and the
|
|
peripherals don't really do genuine PnP. However by examining
|
|
the BIOS info plus the ECU info, the probe routines can cause the
|
|
devices that are PnP to avoid those devices the probe code cannot
|
|
relocate.
|
|
|
|
<p>Then the PnP devices are visited once more and given their I/O,
|
|
DMA, IRQ and Memory-map address assignments. The devices will
|
|
then appear at those locations and remain there until the next
|
|
reboot, although there is nothing that says you can't move them
|
|
around whenever you want.
|
|
|
|
<p>There is a lot of oversimplification above, but you should get
|
|
the general idea.
|
|
|
|
<p>Microsoft took over some of the primary printer status ports to
|
|
do PnP, on the logic that no boards decoded those addresses for
|
|
the opposing I/O cycles. I found a genuine IBM printer board
|
|
that did decode writes of the status port during the early PnP
|
|
proposal review period, but MS said ``tough''. So they do a
|
|
write to the printer status port for setting addresses, plus that
|
|
use that address + <tt/0x800/, and a third I/O port for reading
|
|
that can be located anywhere between <tt/0x200/ and <tt/0x3ff/.
|
|
|
|
<sect1>
|
|
<heading>Will FreeBSD ever support other architectures?</heading>
|
|
|
|
<p>Several different groups have expressed interest in working on
|
|
multi-architecture support for FreeBSD and some people are
|
|
currently working on a port of FreeBSD to the ALPHA, with the
|
|
cooperation of DEC. For general discussion on new architectures,
|
|
use the <tt><platforms@FreeBSD.ORG></tt>
|
|
<ref id="mailing" name="mailing list">.
|
|
|
|
<sect1>
|
|
<heading>I need a major number for a device driver I've written.</heading>
|
|
|
|
<p>This depends on whether or not you plan on making the driver
|
|
publicly available. If you do, then please send us a copy of the
|
|
driver source code, plus the appropriate modifications to
|
|
<tt>files.i386</tt>, a sample configuration file entry, and the
|
|
appropriate <htmlurl url="http://www.freebsd.org/cgi/man.cgi?MAKEDEV"
|
|
name="MAKEDEV"> code to create any special files your device uses. If
|
|
you do not, or are unable to because of licensing restrictions, then
|
|
character major number 32 and block major number 8 have been reserved
|
|
specifically for this purpose; please use them. In any case, we'd
|
|
appreciate hearing about your driver on
|
|
<tt><hackers@FreeBSD.ORG></tt>.
|
|
|
|
</sect>
|
|
|