to make things more interchangeable between it and the FORTH case.
Perhaps requiring the space is a bit too much, but...
Nothing in the tree seems to produce loader.rc files with comment
line, at this time.
introduced by version 1.349 of ports/Mk/bsd.port.mk and originally
submitted by kris.
In particular, it understands the $PORTREVISION (FreeBSD-specific changes
or patches to a port) and $PORTEPOCH (for re-sorting version numbers
when not used or when broken).
as the kernel name. The one very unfortunate consequence is that kernel
as an absolute path loses the priority. It will only be tried after
/boot/${kernel}/${bootfile}. I'll see what can be done about it later.
move file static variable to auto variable, make in6_cksum() work better in
kernel-MP environment. sync with kame.
From: Alfred Perlstein <bright@wintelcom.net>
were not present when dev_mkdb(8) was run.
First the dev_mkdb(8) database is searched, this caters for non-DEVFS
cases where people have renamed a device.
If that fails we ask the kernel using sysctl kern.devname if the device
driver has put a name in the dev_t. This covers DEVFS cloned devices.
If that also fails we format a string which isn't entirely useless.
Load the first of the following kernels to be found:
${kernel} if ${kernel} is an absolute path
/boot/${kernel}/${kernel}
/boot/${kernel}/${bootfile}
${kernel}/${kernel}
${kernel}/${bootfile}
${kernel}
${bootfile}
The last instance of ${kernel} and ${bootfile} will be treated as a
list of semicolon separated file names, and each will be tried in turn,
from left to right.
Also, for each filename loader(8) will try filename, filename.ko,
filename.gz, filename.ko.gz, in that order, but that's not related
to this code.
This resulted in a major reorganization of the code, and much of what
was accumulating on loader.4th was rightly transfered to support.4th.
The semantics of boot-conf and boot also changed. Both will try to load
a kernel the same as above.
After a kernel was loaded, the variable module_path may get changed. Such
change will happen if the kernel was found with a directory prefix. In
that case, the module path will be set to ${directory};${module_path}.
Next, the modules are loaded as usual.
This is intended so kernel="xyzzy" in /boot/loader.conf will load
/boot/xyzzy/kernel.ko, load system modules from /boot/xyzzy/, and
load third party modules from /boot/modules or /modules. If that doesn't
work, it's a bug.
Also, fix a breakage of "boot" which was recently introduced. Boot without
any arguments would fail. No longer. Also, boot will only unload/reload
if the first argument is a path. If no argument exists or the first
argument is a flag, boot will use whatever is already loaded. I hope this
is POLA. That behavior is markedly different from that of boot-conf, which
will always unload/reload.
The semantics introduced here are experimental. Even if the code works,
we might decide this is not the prefered behavior. If you feel so, send
your feedback. (Yeah, this belongs in a HEADS UP or something, but I've
been working for the past 16 hours on this stuff, so gimme a break.)
macros that expand to pass filename and line number information. This is
necessary since we're using inline functions instead of macros now.
Add const to the filename pointers passed througout the mtx and witness
code.
and mtx_exit(). This change tracks the i386 version.
Rename mtx_enter(), mtx_try_enter(), and mtx_exit() and wrap them with cpp
macros that expand to pass filename and line number information. This is
necessary since we're using inline functions instead of macros now.
Add const to the filename pointers passed througout the mtx and witness
code.
Now boot-conf can also receive parameters to be passed to the kernel
being booted. The syntax is the same as in the boot command, so one
boots /kernel.OLD in single-user mode by typing:
boot-conf /kernel.OLD -s instead of
boot-conf -s /kernel.OLD
The syntax still supports use of directory instead of file name, so
boot-conf kernel.OLD -s
may be used to boot /boot/kernel.OLD/kernel.ko in single-user mode.
Notice that if one passes a flag to boot-conf, it will override the
flags set in .conf files, but only for that invocation. If the user
aborts the countdown and tries again without passing any flags, the
flags set in .conf files will be used.
Some factorization was done in the process of enhancing boot-conf,
as it has been growing steadly as features are getting added, becoming
too big for a Forth word. It still could do with more factorization,
as a matter of fact.
Override the builtin "boot" with something based on boot-conf. It will
behave exactly like boot-conf, but booting directly instead of going
through autoboot.
Since we are now pairing kernel and module set in the same directory,
this change to boot makes sense.
