diff options
Diffstat (limited to 'doc/src/makecheck.html')
| -rw-r--r-- | doc/src/makecheck.html | 684 |
1 files changed, 0 insertions, 684 deletions
diff --git a/doc/src/makecheck.html b/doc/src/makecheck.html deleted file mode 100644 index 7fa3a3bcb..000000000 --- a/doc/src/makecheck.html +++ /dev/null @@ -1,684 +0,0 @@ -<html> -<head> -<title>FreeS/WAN "make check" guide</title> -<!-- Changed by: Michael Richardson, 02-Apr-2003 --> -<meta name="keywords" content="Linux, IPsec, VPN, security, FreeSWAN, testing, User-Mode-Linux, UML"> - -<!-- - -Written by Michael Richardson for the Linux FreeS/WAN project -Freely distributable under the GNU General Public License - -More information at www.freeswan.org -Feedback to users@lists.freeswan.org - -$Id: makecheck.html,v 1.1 2004/03/15 20:35:24 as Exp $ - -$Log: makecheck.html,v $ -Revision 1.1 2004/03/15 20:35:24 as -added files from freeswan-2.04-x509-1.5.3 - -Revision 1.25 2003/04/02 20:28:33 mcr - document for NETJIGVERBOSE environment variable. - -Revision 1.24 2003/04/02 02:17:52 mcr - added documentation on "PACKETRATE" - -Revision 1.23 2003/02/27 09:28:24 mcr - added documentation for *_RUN2_SCRIPT. - -Revision 1.22 2003/02/20 20:00:44 mcr - added documentation for ${host}HOST. - -Revision 1.21 2003/02/20 19:56:11 mcr - documented new umlXhost test case. - -Revision 1.20 2002/12/06 02:11:42 mcr - added new test type, module_compile. - -Revision 1.19 2002/12/04 03:47:06 mcr - added documentation of various *TESTDEBUG options in - the testing environment. - -Revision 1.18 2002/10/31 19:01:31 mcr - documentation for RUN_*_SCRIPT. - -Revision 1.17 2002/09/11 19:43:36 mcr - added documentation on format of TESTLIST. - -Revision 1.16 2002/09/11 19:26:48 mcr - renamed umlpluto -> umlplutotest. - -Revision 1.15 2002/07/29 22:27:12 mcr - added kernel_patch_test test type. - -Revision 1.14 2002/06/19 18:24:44 mcr - renamed SCRIPT to INIT_SCRIPT. - -Revision 1.13 2002/06/19 10:06:07 mcr - added nightly.html to the documentation tree. - -Revision 1.12 2002/06/19 09:19:26 mcr - wrote documentation for umlpluto parts of makecheck, - and adjusted scripts for consistency. - -Revision 1.11 2002/06/19 07:26:31 mcr - added FINAL_SCRIPT to be run after sending packets through. - renamed "SCRIPT" to "INIT_SCRIPT" (left compat variable) - -Revision 1.10 2002/06/17 05:40:57 mcr - Added test cases for the "make rpm" machinery. - -Revision 1.9 2002/06/08 17:12:49 mcr - added new libtest test type for use in testing libfreeswan - -Revision 1.8 2002/05/27 00:19:38 mcr - removed reference to single_netjig.png because mkhtml does not - grok it. - -Revision 1.7 2002/05/07 01:31:52 mcr - documented the new "mkinsttest" target type. - -Revision 1.6 2002/05/05 23:10:50 mcr - added documentation of $TEST_TYPE variable. - -Revision 1.5 2002/04/19 22:48:41 mcr - added documentation on NETJIGDEBUG and CONSOLEDIFFDEBUG. - -Revision 1.4 2002/04/01 23:59:46 mcr - added documentation on REF_{PUB,PRIV}_FILTER. - -Revision 1.3 2002/04/01 23:38:46 mcr - redo of updates to makecheck - -Revision 1.2 2002/03/12 21:12:07 mcr - initial stab at documentation on klips testing infrastructure. - - ---> -</head> - -<body> - -<h1><a name="makecheck">How to configure to use "make check"</a></h1> - -<H2>What is "make check"</H2> -<p> -"make check" is a target in the top level makefile. It takes care of -running a number of unit and system tests to confirm that FreeSWAN has -been compiled correctly, and that no new bugs have been introduced. -</p> -<p> -As FreeSWAN contains both kernel and userspace components, doing testing -of FreeSWAN requires that the kernel be simulated. This is typically difficult -to do as a kernel requires that it be run on bare hardware. A technology -has emerged that makes this simpler. This is -<A HREF="http://user-mode-linux.sourceforge.net">User Mode Linux</A>. -</p> - -<p> -User-Mode Linux is a way to build a Linux kernel such that it can run as a process -under another Linux (or in the future other) kernel. Presently, this can only be -done for 2.4 guest kernels. The host kernel can be 2.2 or 2.4. -</p> - -<p> -"make check" expects to be able to build User-Mode Linux kernels with FreeSWAN included. -To do this it needs to have some files downloaded and extracted prior -to running "make check". This is described in the -<A HREF="umltesting.html">UML testing</A> document. -</p> - -<p> -After having run the example in the UML testing document and -successfully brought up the four machine combination, you are ready to -use "make check" -</p> - -<h2>Running "make check"</h2> -<p> -"make check" works by walking the FreeSWAN source tree invoking the -"check" target at each node. At present there are tests defined only -for the <CODE>klips</CODE> directory. These tests will use the UML -infrastructure to test out pieces of the <CODE>klips</CODE> code. -</p> -<p> -The results of the tests can be recorded. If the environment variable -<CODE>$REGRESSRESULTS</CODE> is non-null, then the results of each -test will be recorded. This can be used as part of a nightly -regression testing system, see -<A HREF="nightly.html">Nightly testing</A> for more details. -</p> -<p> -"make check" otherwise prints a minimal amount of output for each -test, and indicates pass/fail status of each test as they are run. -Failed tests do not cause failure of the target in the form of exit -codes. -</p> - -<H1>How to write a "make check" test</H1> - -<h2>Structure of a test</h2> - -<p> -Each test consists of a set of directories under <CODE>testing/</CODE>. -There are directories for <CODE>klips</CODE>, <CODE>pluto</CODE>, <CODE>packaging</CODE> -and <CODE>libraries</CODE>. -Each directory has a list of tests to run is stored in a file called <CODE>TESTLIST</CODE> in that directory. e.g. <CODE>testing/klips/TESTLIST</CODE>. -</P> - -<H2 NAME="TESTLIST">The TESTLIST</H2> -<P> -This isn't actually a shell script. It just looks like one. Some tools other than -/bin/sh process it. Lines that start with # are comments. </P> - -<PRE> -# test-kind directory-containing-test expectation [PR#] -</PRE> - -<P>The first word provides the test type, detailed below. </P> -<P> The second word is the name of the test to run. This the directory -in which the test case is to be found..</P> -<P>The third word may be one of: -<DL> -<DT> blank/good</DT> -<DD>the test is believed to function, report failure</DD> -<DT> bad</DT> -<DD> the test is known to fail, report unexpected success</DD> -<DT> suspended</DT> -<DD> the test should not be run</DD> -</DL> - -<P> -The fourth word may be a number, which is a PR# if the test is -failing. -</P> - -<H2>Test kinds</H2> -The test types are: - -<DL> -<DT>skiptest</DT> -<DD>means run no test.</DD> -<DT>ctltest</DT> -<DD>means run a single system without input/output.</DD> -<DT>klipstest</DT> -<DD>means run a single system with input/output networks</DD> -<DT><A HREF="#umlplutotest">umlplutotest</A></DT> -<DD>means run a pair of systems</DD> -<DT><A HREF="#umlXhost">umlXhost</A></DT> -<DD>run an arbitrary number of systems</DT> -<DT>suntest (TBD)</DT> -<DD>means run a quad of east/west/sunrise/sunset</DD> -<DT>roadtest (TBD)</DT> -<DD>means run a trio of east-sunrise + warrior</DD> -<DT>extrudedtest (TBD)</DT> -<DD>means run a quad of east-sunrise + warriorsouth + park</DD> -<DT>mkinsttest</TD> -<DD>a test of the "make install" machinery.</DD> -<DT>kernel_test_patch</TD> -<DD>a test of the "make kernelpatch" machinery.</DD> -</DL> - -Tests marked (TBD) have yet to be fully defined. -</p> - -<p> -Each test directory has a file in it called <CODE>testparams.sh</CODE>. -This file sets a number of environment variables to define the -parameters of the test. -</p> - -<H2>Common parameters</H2> -<DL> -<DT>TESTNAME</DT> -<DD>the name of the test (repeated for checking purposes)</DD> - -<DT>TEST_TYPE</DT> -<DD>the type of the test (repeat of type type above)</DD> - -<DT>TESTHOST</DT> -<DD>the name of the UML machine to run for the test, typically "east" - or "west"</DD> - -<DT>TEST_PURPOSE</DT> -<DD>The purpose of the test is one of: - -<DL> -<DT>goal</DT> -<DD>The goal purpose is where a test is defined for code that is not yet -finished. The test indicates when the goals have in fact been reached.</DD> -<DT>regress</DT> -<DD>This is a test to determine that a previously existing bug has been repaired. This -test will initially be created to reproduce the bug in isolation, and then the bug will -be fixed.</DD> -<DT>exploit</DT> -<DD>This is a set of packets/programs that causes a vulnerability to be -exposed. It is a specific variation of the regress option.</DD> -</DL> -</DD> - -<DT>TEST_GOAL_ITEM<DT> -<DD>in the case of a goal test, this is a reference to the requirements document</DD> - -<DT>TEST_PROB_REPORT</DT> -<DD>in the case of regression test, this the problem report number from GNATS</DD> - -<DT>TEST_EXPLOIT_URL</DT> -<DD>in the case of an exploit, this is a URL referencing the paper explaining -the origin of the test and the origin of exploit software</DD> - -<DT>REF_CONSOLE_OUTPUT</DT> -<DD>a file in the test directory that contains the sanitized console - output against which to compare the output of the actual test.</DD> -<DT>REF_CONSOLE_FIXUPS</DT> -<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to - apply to sanitize the console output of the machine under test. - These are typically perl, awk or sed scripts that remove things in - the kernel output that change each time the test is run and/or - compiled. -</DD> -<DT>INIT_SCRIPT</DT> -<DD><p>a file of commands that is fed into the virtual machine's console - in single user mode prior to starting the tests. This file will - usually set up any eroute's and SADB entries that are required for - the test. </p> -<p>Lines beginning with # are skipped. Blank lines are - skipped. Otherwise, a shell prompted is waited for each time - (consisting of <CODE>\n#</CODE>) and then the command is sent. - Note that the prompt is waited for before the command and not after, - so completion of the last command in the script is not - required. This is often used to invoke a program to monitor the - system, e.g. <CODE>ipsec pf_key</CODE>. -</P> -<DT>RUN_SCRIPT</DT> -<DD><P>a file of commands that is fed into the virtual machine's console - in single user mode, before the packets are sent. On single machine - tests, this script doesn't provide any more power than INIT_SCRIPT, - but is implemented for consistency's sake.</P> -<DT>FINAL_SCRIPT</DT> -<DD><p>a file of commands that is fed into the virtual machine's console - in single user mode after the final packet is sent. Similar to INIT_SCRIPT, - above. If not specified, then the single command "halt" is sent. - If specified, then the script should end with a halt command to - nicely shutdown the UML. -</P> -<DT>CONSOLEDIFFDEBUG</DT> -<DD>If set to "true" then the series of console fixups (see REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should be set to "false", or unset otherwise)</DD> -<DT>NETJIGDEBUG</DT> -<DD>If set to "true" then the series of console fixups (see REF_CONSOLE_FIXUPS) will be output after it is constructed. (It should be set to "false", or unset otherwise)</DD> -<DT>NETJIGTESTDEBUG</DT> -<DD> If set to "netjig", then the results of talking to the <CODE>uml_netjig</CODE> -will be printed to stderr during the test. In addition, the jig will -be invoked with --debug, which causes it to log its process ID, and -wait 60 seconds before continuing. This can be used if you are trying -to debug the <CODE>uml_netjig</CODE> program itself.</DT> -<DT>HOSTTESTDEBUG</DT> -<DD> If set to "hosttest", then the results of taling to the consoles of the UMLs will -be printed to stderr during the test.</DT> -<DT>NETJIGWAITUSER</DT> -<DD> If set to "waituser", then the scripts will wait forever for user - input before they shut the tests down. Use this is if you are - debugging through the kernel.</DD> - -<DT>PACKETRATE</DT> -<DD> A number, in miliseconds (default is 500ms) at which packets will - be replayed by the netjig.</DD> -</DL> - - -<H2>KLIPStest paramaters</H2> -<P> -The klipstest function starts a program -(<CODE>testing/utils/uml_netjig/uml_netjig</CODE>) to -setup a bunch of I/O sockets (that simulate network interfaces). It -then exports the references to these sockets to the environment and -invokes (using system()) a given script. It waits for the script to -finish. -</P> - -<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> --> - -<P> -The script invoked (<CODE>testing/utils/host-test.tcl</CODE>) is a TCL -<A HREF="http://expect.nist.gov/">expect</A> script that arranges to start the UML -and configure it appropriately for the test. The configuration is done -with the script given above for <VAR>INIT_SCRIPT</VAR>. The TCL script then forks, -leaves the UML in the background and exits. uml_netjig continues. It then -starts listening to the simulated network answering ARPs and inserting -packets as appropriate. -</P> - -<P> -The klipstest function invokes <CODE>uml_netjig</CODE> with arguments -to capture output from network interface(s) and insert packets as -appropriate: -<DL> -<DT>PUB_INPUT</DT> -<DD>a <A HREF="http://www.tcpdump.org/">pcap</A> file to feed in on - the public (encrypted) interface. (typically, eth1)</DD> -<DT>PRIV_INPUT</DT> -<DD>a pcap file to feed in on the private (plain-text) interface - (typically, eth0).</DD> -<DT>REF_PUB_OUTPUT</DT> -<DD>a text file containing tcpdump output. Packets on the public - (eth1) interface are captured to a - <A HREF="http://www.tcpdump.org/">pcap</A> file by - <CODE>uml_netjig</CODE>. The klipstest function then uses tcpdump on - the file to produce text output, which is compared to the file given.</DD> -<DT>REF_PUB_FILTER</DT> -<DD>a program that will filter the TCPDUMP output to do further processing. Defaults to "cat".</DD> -<DT>REF_PRIV_OUTPUT</DT> -<DD>a text file containing tcpdump output. Packets on the private - (eth0) interface are captured and compared after conversion by - tcpdump, as with <VAR>REFPUBOUTPUT</VAR>.</DD> -<DT>REF_PRIV_FILTER</DT> -<DD>a program that will filter the TCPDUMP output to do further processing. Defaults to "cat".</DD> -<DT>EXITONEMPTY</DT> -<DD>a flag for <CODE>uml_netjig</CODE>. It should contain - "--exitonempty" of uml_netjig should exit when all of the input - (<VAR>PUBINPUT</VAR>,<VAR>PRIVINPUT</VAR>) packets have been injected.</DD> -<DT>ARPREPLY</DT> -<DD>a flag for <CODE>uml_netjig</CODE>. It should contain "--arpreply" - if <CODE>uml_netjig</CODE> should reply to ARP requests. One will - typically set this to avoid having to fudge the ARP cache manually.</DD> -<DT>TCPDUMPFLAGS</DT> -<DD>a set of flags for the tcpdump used when converting captured - output. Typical values will include "-n" to turn off DNS, and often - "-E" to set the decryption key (tcpdump 3.7.1 and higher only) for - ESP packets. The "-t" flag (turn off timestamps) is provided automatically</DD> - -<DT>NETJIG_EXTRA</DT> -<DD>additional comments to be sent to the netjig. This may arrange to - record or create additional networks, or may toggle options. -</DL> - -<H2>mkinsttest paramaters</H2> -<P> -The basic concept of the <CODE>mkinsttest</CODE> test type is that it -performs a "make install" to a temporary $DESTDIR. The resulting tree can then -be examined to determine if it was done properly. The files can be uninstalled -to determine if the file list was correct, or the contents of files can be -examined more precisely. -</P> - -<DL> -<DT>INSTALL_FLAGS</DT> -<DD>If set, then an install will be done. This provides the set of flags to -provide for the install. The target to be used (usually "install") must be -among the flags. </DD> -<DT>POSTINSTALL_SCRIPT</DT> -<DD>If set, a script to run after initial "make install". Two arguments are provided: an absolute path to the root of the FreeSWAN src tree, and an absolute path to the temporary installation area.</DD> -<DT>INSTALL2_FLAGS</DT> -<DD>If set, a second install will be done using these flags. Similarly to -INSTALL_FLAGS, the target must be among the flags. </DD> -<DT>UNINSTALL_FLAGS</DT> -<DD>If set, an uninstall will be done using these flags. Similarly to -INSTALL_FLAGS, the target (usually "uninstall") must be among the flags.</DD> -<DT>REF_FIND_f_l_OUTPUT</DT> -<DD>If set, a <CODE>find $ROOT ( -type f -or -type -l )</CODE> will be done to get a list of a real files and symlinks. The resulting file will be compared -to the file listed by this option.</DD> -<DT>REF_FILE_CONTENTS</DT> -<DD>If set, it should point to a file containing records for the form: -<PRE> - <VARIABLE>reffile</VARIABLE> <VARIABLE>samplefile</VARIABLE> -</PRE> -one record per line. A diff between the provided reference file, and the -sample file (located in the temporary installation root) will be done for -each record. -</DD> -</DL> - -<H2>rpm_build_install_test paramaters</H2> -<P> -The <CODE>rpm_build_install_test</CODE> type is to verify that the proper -packing list is produced by "make rpm", and that the mechanisms for -building the kernel modules produce consistent results. -</P> - -<DL> -<DT>RPM_KERNEL_SOURCE</DT> -<DD>Point to an extracted copy of the RedHat kernel source code. Variables -from the environment may be used.</DD> -<DT>REF_RPM_CONTENTS</DT> -<DD>This is a file containing one record per line. Each record consists -of a RPM name (may contain wildcards) and a filename to compare the -contents to. The RPM will be located and a file list will be produced with -rpm2cpio.</DD> -</DL> - -<H2>libtest paramaters</H2> -<P> -The libtest test is for testing library routines. The library file is -expected to provided an <CODE>#ifdef</CODE> by the name of -<VAR>library</VAR><CODE_MAIN</CODE>. -The libtest type invokes the C compiler to compile this file, links it against -<CODE>libfreeswan.a</CODE> (to resolve any other dependancies) and runs the -test with the <CODE>-r</CODE> argument to invoke a regression test.</P> -<P>The library test case is expected to do a self-test, exiting with status code 0 if everything is okay, and with non-zero otherwise. A core dump (exit code greater than 128) is noted specifically. -</P> -<P> -Unlike other tests, there are no subdirectories required, or other -parameters to set. -</P> - -<H2 NAME="umlplutotest">umlplutotest paramaters</H2> -<P> -The umlplutotest function starts a pair of user mode line processes. -This is a 2-host version of umlXhost. The "EAST" and "WEST" slots are defined. -</P> - -<H2 NAME="umlXhost">umlXhost parameters</H2> -<P> -The umlXtest function starts an arbitrary number of user mode line processes. -</P> - -<!-- <IMG SRC="single_netjig.png" ALT="block diagram of uml_netjig"> --> - -<P> -The script invoked (<CODE>testing/utils/Xhost-test.tcl</CODE>) is a TCL -<A HREF="http://expect.nist.gov/">expect</A> script that arranges to start each -UML -and configure it appropriately for the test. It then starts listening -(using uml_netjig) to the simulated network answering ARPs and -inserting packets as appropriate. -</P> - -<P> -umlXtest has a series of slots, each of which should be filled by a host. -The list of slots is controlled by the variable, XHOST_LIST. This variable -should be set to a space seperated list of slots. The former umlplutotest -is now implemented as a variation of the umlXhost test, -with XHOST_LIST="EAST WEST". -</P> - -<P> -For each host slot that is defined, a series of variables should be -filled in, defining what configuration scripts to use for that host. -</P> - -<P> -The following are used to control the console input and output to the system. -Where the string ${host} is present, the host slot should be filled in. -I.e. for the two host system with XHOST_LIST="EAST WEST", then the -variables: EAST_INIT_SCRIPT and WEST_INIT_SCRIPT will exist. -<DL> -<DT>${host}HOST</DT> -<DD>The name of the UML host which will fill this slot</DD> -<DT>${host}_INIT_SCRIPT</DT> -<DD><p>a file of commands that is fed into the virtual machine's console - in single user mode prior to starting the tests. This file will - usually set up any eroute's and SADB entries that are required for - the test. Similar to INIT_SCRIPT, above.</p> -<DT>${host}_RUN_SCRIPT</DT> -<DD><P>a file of commands that is fed into the virtual machine's console - in single user mode, before the packets are sent. This set of - commands is run after all of the virtual machines are initialized. - I.e. after EAST_INIT_SCRIPT <B>AND</B> WEST_INIT_SCRIPT. This script - can therefore do things that require that all machines are properly - configured.</P> -<DT>${host}_RUN2_SCRIPT</DT> -<DD><P>a file of commands that is fed into the virtual machine's console - in single user mode, after the packets are sent. This set of - commands is run before any of the virtual machines have been shut - down. (I.e. before EAST_FINAL_SCRIPT <B>AND</B> WEST_FINAL_SCRIPT.) - This script can therefore catch post-activity status reports.</P> -<DT>${host}_FINAL_SCRIPT</DT> -<DD><p>a file of commands that is fed into the virtual machine's console - in single user mode after the final packet is sent. Similar to INIT_SCRIPT, - above. If not specified, then the single command "halt" is sent. Note that - when this script is run, the other virtual machines may already have been killed. - If specified, then the script should end with a halt command to nicely - shutdown the UML. -</P> -<DT>REF_${host}_CONSOLE_OUTPUT</DT> -<DD>Similar to REF_CONSOLE_OUTPUT, above.</DT> -</DL> -</P> - -<P>Some additional flags apply to all hosts: -<DL> -<DT>REF_CONSOLE_FIXUPS</DT> -<DD>a list of scripts (found in <CODE>klips/test/fixups</CODE>) to - apply to sanitize the console output of the machine under test. - These are typically perl, awk or sed scripts that remove things in - the kernel output that change each time the test is run and/or - compiled. -</DD> -</DL> -</P> - -<P> In addition to input to the console, the networks may have input -fed to them: -<DL> -<DT>EAST_INPUT/WEST_INPUT</DT> -<DD>a <A HREF="http://www.tcpdump.org/">pcap</A> file to feed in on - the private network side of each network. The "EAST" and "WEST" here -refer to the networks, not the hosts.</DD> -<DT>REF_PUB_FILTER</DT> -<DD>a program that will filter the TCPDUMP output to do further processing. Defaults to "cat".</DD> -<DT>REF_EAST_FILTER/REF_WEST_FILTER</DT> -<DD>a program that will filter the TCPDUMP output to do further processing. Defaults to "cat".</DD>< -<DT>TCPDUMPFLAGS</DT> -<DD>a set of flags for the tcpdump used when converting captured - output. Typical values will include "-n" to turn off DNS, and often - "-E" to set the decryption key (tcpdump 3.7.1 and higher only) for - ESP packets. The "-t" flag (turn off timestamps) is provided automatically</DD> -<DT>REF_EAST_OUTPUT/REF_WEST_OUTPUT</DT> -<DD>a text file containing tcpdump output. Packets on the private - (eth0) interface are captured and compared after conversion by - tcpdump, as with <VAR>REF_PUB_OUTPUT</VAR>.</DD> -</P> - -<P> -There are two additional environment variables that may be set on the -command line: -<DL> -<DT> NETJIGVERBOSE=verbose export NETJIGVERBOSE</DT> -<DD> If set, then the test output will be "chatty", and let you know what - commands it is running, and as packets are sent. Without it set, the - output is limited to success/failure messages.</DD> -<DT> NETJIGTESTDEBUG=netjig export NETJIGTESTDEBUG</DT> -<DD> This will enable debugging of the communication with uml_netjig, - and turn on debugging in this utility. - This does not imply NETJIGVERBOSE.</DL> -<DT> HOSTTESTDEBUG=hosttest export HOSTTESTDEBUG</DT> -<DD> This will show all interactions with the user-mode-linux - consoles</DD> -</DL> -</P> - -<H2 NAME="kernelpatch">kernel_patch_test paramaters</H2> -<P> -The kernel_patch_test function takes some kernel source, copies it with -lndir, and then applies the patch as produced by "make kernelpatch". -</P> -<P> -The following are used to control the input and output to the system: -<DL> -<DT>KERNEL_NAME</DT> -<DD>the kernel name, typically something like "linus" or "rh"</DD> -<DT>KERNEL_VERSION</DT> -<DD>the kernel version number, as in "2.2" or "2.4".</DD> -<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT> -<DD>This variable should set in the environment, probably in - ~/freeswan-regress-env.sh. Examples of this variables would be - KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point - to an extracted copy of the kernel source in question.</DD> -<DT>REF_PATCH_OUTPUT</DT> -<DD>a copy of the patch output to compare against</DD> -<DT>KERNEL_PATCH_LEAVE_SOURCE</DT> -<DD>If set to a non-empty string, then the patched kernel source is not - removed at the end of the test. This will typically be set in the - environment while debugging.</DD> -</DL> -</P> - -<H2 NAME="modtest">module_compile paramaters</H2> -<P> -The module_compile test attempts to build the KLIPS module against a -given set of kernel source. This is also done by the RPM tests, but -in a very specific manner. -</P> -<P> -There are two variations of this test - one where the kernel either -doesn't need to be configured, or is already done, and tests were there -is a local configuration file. -</P> -<P> -Where the kernel doesn't need to be configured, the kernel source that -is found is simply used. It may be a RedHat-style kernel, where one -can cause it to configure itself via rhconfig.h-style definitions. Or, -it may just be a kernel tree that has been configured. -</P> -<P> -If the variable KERNEL_CONFIG_FILE is set, then a new directory is -created for the kernel source. It is populated with lndir(1). The referenced -file is then copied in as .config, and "make oldconfig" is used to configure -the kernel. This resulting kernel is then used as the reference source. -</P> -<p> -In all cases, the kernel source is found the same was for the kernelpatch -test, i.e. via KERNEL_VERSION/KERNEL_NAME and KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC.</P> -<P> -Once there is kernel source, the module is compiled using the top-level -"make module" target. -</P> -<P> -The test is considered successful if an executable is found in OUTPUT/module/ipsec.o at the end of the test. -</P> -<DL> -<DT>KERNEL_NAME</DT> -<DD>the kernel name, typically something like "linus" or "rh"</DD> -<DT>KERNEL_VERSION</DT> -<DD>the kernel version number, as in "2.2" or "2.4".</DD> -<DT>KERNEL_${KERNEL_NAME}${KERNEL_VERSION}_SRC</DT> -<DD>This variable should set in the environment, probably in - ~/freeswan-regress-env.sh. Examples of this variables would be - KERNEL_LINUS2_0_SRC or KERNEL_RH7_3_SRC. This variable should point - to an extracted copy of the kernel source in question.</DD> -<DT>KERNEL_CONFIG_FILE</DT> -<DD>The configuration file for the kernel.</DD> -<DT>KERNEL_PATCH_LEAVE_SOURCE</DT> -<DD>If set to a non-empty string, then the configured kernel source is not - removed at the end of the test. This will typically be set in the - environment while debugging.</DD> -<DT>MODULE_DEF_INCLUDE</DT> -<DD>The include file that will be used to configure the KLIPS module, and - possibly the kernel source. </DD> -</DL> - -<H1>Current pitfalls</H1> - -<DL> -<DT> "tcpdump dissector" not available. </DT> -<DD> This is a non-fatal warning. If uml_netjig is invoked with the -t - option, then it will attempt to use tcpdump's dissector to decode - each packet that it processes. The dissector is presently not - available, so this option it normally turned off at compile time. - The dissector library will be released with tcpdump version - 4.0.</DD> -</DL> - -</body> -</html>
\ No newline at end of file |