
setjmp/longjmp:
---------------

    Bootconf uses a special version of setjmp/longjmp that allows it to
    jump over a realmode driver's stack.  If you want to use setjmp/longjmp
    from bootconf, you must use:

	#include "setjmp.h"

    You'll get a link error if you try:

	#include <setjmp.h>

Automatic "boot -r":
--------------------

    If the addition of an ISA card causes a DCD to move, it will be necessary
    to re-build the "/dev" directory after the kernel comes up (because the
    device names may have changed).  It's a bit much to ask the user to note
    when this happens, so bootconf notes it instead;  namely the "Reconf_escd"
    flag (see "escd.h") is set whenever this happens.  Unfortunately, this
    flag isn't be propagated back to the 2nd level boot.  What needs to happen
    is for the "build_tree" routine to check this flag and set appropriate
    boot args when it's set.

Configuring BIOS primary:
-------------------------

    This isn't completely tested.  In particular, I don't really know whether
    or not it's possible to read from the BIOS primary after the driver has
    been reprogrammed.  To test this one must:

	1. Install 5.6 on a system with no IDE controller (or with the IDE
	   controller disabled) and a PnP SCSI cards (such as the AHA1542CP).
	   Make sure you can boot in the normal case.

        2. Run bootconf and add an ISA device (e.g, a sound card) that con-
	   flicts with the PnP SCIS adapter's base port address.  Then try
	   to boot -- and make sure the SCSI adapter's bas port address has
	   moved.

Function matching between drivers & CFG files:
----------------------------------------------

    I've mentioned this before, but it's very important that the configuration
    set up by a driver's legacy probe routine be one of the valid configu-
    rations listed in the corresponding CFG file.  We haven't been giving this
    much thought up to now because we've been more concerned with just getting
    the drivers to work.  Recently, however, Dennis has been filing bug re-
    ports that are the direct result of driver/CFG file mismatches.  Sometimes,
    these mismatches will be easy to fix (e.g, the driver forgets to reserve
    an IRQ).  You should also make sure that the default driver device name 
    (i.e, the first alias under which the driver is know) matches the CFG file
    name -- and make sure the board name in the CFG file mathes the name of
    the CFG file!

    I suspect that the trickiest CFG/driver mismatches will involve functions.
    To fix bugs of this sort, read the CFG file to determine which resources
    are listed under what functions.  Then check the driver's legacy probe
    routine to ensure that it's issuing "set_res(fid, ...)" calls at the
    apropriate place to get resources associated with the proper functions.

    If, for example, the CFG file looks like this:

		FUNCTION = "Port address"
		  TYPE = "ABC"
		    CHOICE
			Port = 200h
		    CHOICE
			Port = 300h
		    CHOICE
			   ...

		FUNCTION = "IRQ setting"
   		  TYPE = "XYZ"
		    CHOICE
			IRQ = 5
		    CHOICE
			IRQ = 9
		    CHOICE

			   ...

   Then, to remain consistant, the driver must issue "set_res" calls in the
   following sequence.

		if (set_res("port", &port_choice, ...) == 0) {

		    /* Mark end of 1st function */
		    set_res("fid", "ABC", ...);

		    if (set_res("irq", &irq_choice, ...) == 0) {

			/* Mark end of 2nd function */
			set_res("fid", "XYZ", ...);
		    }
		}

   You may, of course, decide that the CFG file is broken rather than the
   driver.  If so, you can collapse everything into a single function (which
   eliminates the need for "set_res(fid, ...)" calls):


		FUNCTION = "Port & IRQ"
		  TYPE = "ABC,XYZ"
		     CHOICE
			FREE
			PORT = 200h | 300h | ...
		     CHOICE
			FREE
			IRQ = 5 | 9 | ...

   (The "FREE" keyword means that the choices of IRQ and PORT are independent
   of one another.  If this isn't the case, you'll have to get more creative
   about how you code your CFG file -- see the EISA spec for details).

   After making CFG file changes, run "bootconf -c", then try adding a device
   of that type by hand and play around with various resource settings.  You
   want to make sure the CFG file is self-consistant before attempting to
   match it up with configurations generated by the driver.

Unix version:
-------------

   The UNIX version of bootconf is no longer working properly.  It works fine
   as long as you stay in the "Device configuration" screens, but it dumps
   core as soon as you attempt to boot.  I suspect that there are bugs in my
   bef simulator, since I haven't done any work on it in quite a while and
   the bef interface has changed a bit in the interim.  I doubt that anyone
   really cares about this (I seem to be the only one who even compiles boot-
   conf on both systems), but I figured I should warn you about it anyway.
