diff options
Diffstat (limited to 'FAQ/hackers.sgml')
| -rw-r--r-- | FAQ/hackers.sgml | 265 |
1 files changed, 265 insertions, 0 deletions
diff --git a/FAQ/hackers.sgml b/FAQ/hackers.sgml new file mode 100644 index 0000000000..50ccde65c8 --- /dev/null +++ b/FAQ/hackers.sgml @@ -0,0 +1,265 @@ +<!-- $Id: hackers.sgml,v 1.1 1997-11-03 08:53:45 max 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 your tag value, if any, should be `.' and your release name + should be cvs: + + <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> + |