1999-03-09 14:06:55 +00:00
|
|
|
\ Copyright (c) 1999 Daniel C. Sobral <dcs@freebsd.org>
|
|
|
|
|
\ All rights reserved.
|
|
|
|
|
\
|
|
|
|
|
\ Redistribution and use in source and binary forms, with or without
|
|
|
|
|
\ modification, are permitted provided that the following conditions
|
|
|
|
|
\ are met:
|
|
|
|
|
\ 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
\ notice, this list of conditions and the following disclaimer.
|
|
|
|
|
\ 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
\ notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
\ documentation and/or other materials provided with the distribution.
|
|
|
|
|
\
|
|
|
|
|
\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
\ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
\ ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
|
\ FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
|
\ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
|
\ OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
|
\ HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
|
\ LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
|
\ OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
|
\ SUCH DAMAGE.
|
|
|
|
|
\
|
1999-08-28 01:08:13 +00:00
|
|
|
\ $FreeBSD$
|
1999-03-09 14:06:55 +00:00
|
|
|
|
2000-06-14 19:39:31 +00:00
|
|
|
s" arch-i386" environment? [if] [if]
|
|
|
|
|
s" loader_version" environment? [if]
|
2001-12-11 00:49:34 +00:00
|
|
|
11 < [if]
|
|
|
|
|
.( Loader version 1.1+ required) cr
|
2000-06-14 19:39:31 +00:00
|
|
|
abort
|
|
|
|
|
[then]
|
|
|
|
|
[else]
|
|
|
|
|
.( Could not get loader version!) cr
|
|
|
|
|
abort
|
|
|
|
|
[then]
|
|
|
|
|
[then] [then]
|
2000-06-07 22:19:49 +00:00
|
|
|
|
2001-05-29 23:49:10 +00:00
|
|
|
256 dictthreshold ! \ 256 cells minimum free space
|
|
|
|
|
2048 dictincrease ! \ 2048 additional cells each time
|
|
|
|
|
|
1999-03-09 14:06:55 +00:00
|
|
|
include /boot/support.4th
|
|
|
|
|
|
Enhance boot-conf.
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.
2000-09-08 21:11:57 +00:00
|
|
|
only forth also support-functions also builtins definitions
|
|
|
|
|
|
2011-12-30 06:24:59 +00:00
|
|
|
: try-menu-unset
|
2012-01-09 20:25:14 +00:00
|
|
|
\ menu-unset may not be present
|
|
|
|
|
s" beastie_disable" getenv
|
|
|
|
|
dup -1 <> if
|
|
|
|
|
s" YES" compare-insensitive 0= if
|
|
|
|
|
exit
|
|
|
|
|
then
|
|
|
|
|
else
|
|
|
|
|
drop
|
|
|
|
|
then
|
2011-12-30 06:24:59 +00:00
|
|
|
s" menu-unset"
|
2012-01-09 20:25:14 +00:00
|
|
|
sfind if
|
|
|
|
|
execute
|
|
|
|
|
else
|
|
|
|
|
drop
|
2011-12-30 06:24:59 +00:00
|
|
|
then
|
|
|
|
|
;
|
|
|
|
|
|
Enhance boot-conf.
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.
2000-09-08 21:11:57 +00:00
|
|
|
: boot
|
2000-09-16 21:04:49 +00:00
|
|
|
0= if ( interpreted ) get_arguments then
|
Factorize, reorganize, and move code around.
The boot-conf and boot code had various bugs, and some of it was big,
ugly, unwieldy, and, sometimes, plain incorrect. I'm just about
completely replaced these ugly parts with something much more manageable.
Minor changes were made to the well-factorized parts of it, to accomodate
the new code.
Of note:
* make sure boot-conf has the exact same behavior wrt boot order
as start.
* Correct both boot and boot-conf so they'll work correctly when
compiled in, as they both had some bugs, minor and major.
* Remove all the crud from loader.4th back into support.4th, for
the first time since boot-conf was first improved. Hurray!
I'm fairly satisfied with the code at this time. Time to see about those
man pages...
2000-09-15 08:05:52 +00:00
|
|
|
|
First tackle at trying to handle the New Deal on kernels.
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.)
2000-09-09 04:52:34 +00:00
|
|
|
\ Unload only if a path was passed
|
Factorize, reorganize, and move code around.
The boot-conf and boot code had various bugs, and some of it was big,
ugly, unwieldy, and, sometimes, plain incorrect. I'm just about
completely replaced these ugly parts with something much more manageable.
Minor changes were made to the well-factorized parts of it, to accomodate
the new code.
Of note:
* make sure boot-conf has the exact same behavior wrt boot order
as start.
* Correct both boot and boot-conf so they'll work correctly when
compiled in, as they both had some bugs, minor and major.
* Remove all the crud from loader.4th back into support.4th, for
the first time since boot-conf was first improved. Hurray!
I'm fairly satisfied with the code at this time. Time to see about those
man pages...
2000-09-15 08:05:52 +00:00
|
|
|
dup if
|
|
|
|
|
>r over r> swap
|
First tackle at trying to handle the New Deal on kernels.
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.)
2000-09-09 04:52:34 +00:00
|
|
|
c@ [char] - <> if
|
|
|
|
|
0 1 unload drop
|
|
|
|
|
else
|
2000-10-09 11:29:40 +00:00
|
|
|
s" kernelname" getenv? if ( a kernel has been loaded )
|
2011-12-30 06:24:59 +00:00
|
|
|
try-menu-unset
|
2000-10-09 11:29:40 +00:00
|
|
|
1 boot exit
|
2000-09-16 19:49:52 +00:00
|
|
|
then
|
2000-10-09 11:29:40 +00:00
|
|
|
load_kernel_and_modules
|
|
|
|
|
?dup if exit then
|
2011-12-30 06:24:59 +00:00
|
|
|
try-menu-unset
|
2000-09-25 11:18:02 +00:00
|
|
|
0 1 boot exit
|
First tackle at trying to handle the New Deal on kernels.
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.)
2000-09-09 04:52:34 +00:00
|
|
|
then
|
|
|
|
|
else
|
2000-10-09 11:29:40 +00:00
|
|
|
s" kernelname" getenv? if ( a kernel has been loaded )
|
2011-12-30 06:24:59 +00:00
|
|
|
try-menu-unset
|
2000-10-09 11:29:40 +00:00
|
|
|
1 boot exit
|
2000-09-16 19:49:52 +00:00
|
|
|
then
|
2000-10-09 11:29:40 +00:00
|
|
|
load_kernel_and_modules
|
|
|
|
|
?dup if exit then
|
2011-12-30 06:24:59 +00:00
|
|
|
try-menu-unset
|
2000-09-25 11:18:02 +00:00
|
|
|
0 1 boot exit
|
First tackle at trying to handle the New Deal on kernels.
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.)
2000-09-09 04:52:34 +00:00
|
|
|
then
|
2000-09-16 20:20:44 +00:00
|
|
|
load_kernel_and_modules
|
Enhance boot-conf.
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.
2000-09-08 21:11:57 +00:00
|
|
|
?dup 0= if 0 1 boot then
|
|
|
|
|
;
|
|
|
|
|
|
2011-12-30 06:24:59 +00:00
|
|
|
\ ***** boot-conf
|
|
|
|
|
\
|
|
|
|
|
\ Prepares to boot as specified by loaded configuration files.
|
|
|
|
|
|
Enhance boot-conf.
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.
2000-09-08 21:11:57 +00:00
|
|
|
: boot-conf
|
2000-09-16 21:04:49 +00:00
|
|
|
0= if ( interpreted ) get_arguments then
|
First tackle at trying to handle the New Deal on kernels.
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.)
2000-09-09 04:52:34 +00:00
|
|
|
0 1 unload drop
|
2000-09-16 20:20:44 +00:00
|
|
|
load_kernel_and_modules
|
Enhance boot-conf.
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.
2000-09-08 21:11:57 +00:00
|
|
|
?dup 0= if 0 1 autoboot then
|
1999-03-09 14:06:55 +00:00
|
|
|
;
|
|
|
|
|
|
Enhance boot-conf.
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.
2000-09-08 21:11:57 +00:00
|
|
|
also forth definitions also builtins
|
Factorize, reorganize, and move code around.
The boot-conf and boot code had various bugs, and some of it was big,
ugly, unwieldy, and, sometimes, plain incorrect. I'm just about
completely replaced these ugly parts with something much more manageable.
Minor changes were made to the well-factorized parts of it, to accomodate
the new code.
Of note:
* make sure boot-conf has the exact same behavior wrt boot order
as start.
* Correct both boot and boot-conf so they'll work correctly when
compiled in, as they both had some bugs, minor and major.
* Remove all the crud from loader.4th back into support.4th, for
the first time since boot-conf was first improved. Hurray!
I'm fairly satisfied with the code at this time. Time to see about those
man pages...
2000-09-15 08:05:52 +00:00
|
|
|
|
Enhance boot-conf.
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.
2000-09-08 21:11:57 +00:00
|
|
|
builtin: boot
|
2000-06-07 22:10:05 +00:00
|
|
|
builtin: boot-conf
|
Factorize, reorganize, and move code around.
The boot-conf and boot code had various bugs, and some of it was big,
ugly, unwieldy, and, sometimes, plain incorrect. I'm just about
completely replaced these ugly parts with something much more manageable.
Minor changes were made to the well-factorized parts of it, to accomodate
the new code.
Of note:
* make sure boot-conf has the exact same behavior wrt boot order
as start.
* Correct both boot and boot-conf so they'll work correctly when
compiled in, as they both had some bugs, minor and major.
* Remove all the crud from loader.4th back into support.4th, for
the first time since boot-conf was first improved. Hurray!
I'm fairly satisfied with the code at this time. Time to see about those
man pages...
2000-09-15 08:05:52 +00:00
|
|
|
|
2000-06-07 22:10:05 +00:00
|
|
|
only forth definitions also support-functions
|
|
|
|
|
|
2011-05-28 08:50:38 +00:00
|
|
|
include /boot/check-password.4th
|
1999-11-24 17:56:40 +00:00
|
|
|
|
1999-03-09 14:06:55 +00:00
|
|
|
\ ***** start
|
|
|
|
|
\
|
|
|
|
|
\ Initializes support.4th global variables, sets loader_conf_files,
|
|
|
|
|
\ process conf files, and, if any one such file was succesfully
|
|
|
|
|
\ read to the end, load kernel and modules.
|
|
|
|
|
|
|
|
|
|
: start ( -- ) ( throws: abort & user-defined )
|
|
|
|
|
s" /boot/defaults/loader.conf" initialize
|
|
|
|
|
include_conf_files
|
2002-05-24 02:28:58 +00:00
|
|
|
include_nextboot_file
|
1999-03-09 14:06:55 +00:00
|
|
|
\ Will *NOT* try to load kernel and modules if no configuration file
|
|
|
|
|
\ was succesfully loaded!
|
|
|
|
|
any_conf_read? if
|
|
|
|
|
load_kernel
|
|
|
|
|
load_modules
|
|
|
|
|
then
|
|
|
|
|
;
|
|
|
|
|
|
1999-05-14 18:59:27 +00:00
|
|
|
\ ***** initialize
|
|
|
|
|
\
|
|
|
|
|
\ Overrides support.4th initialization word with one that does
|
|
|
|
|
\ everything start one does, short of loading the kernel and
|
|
|
|
|
\ modules. Returns a flag
|
|
|
|
|
|
|
|
|
|
: initialize ( -- flag )
|
|
|
|
|
s" /boot/defaults/loader.conf" initialize
|
|
|
|
|
include_conf_files
|
2002-05-24 02:28:58 +00:00
|
|
|
include_nextboot_file
|
1999-05-14 18:59:27 +00:00
|
|
|
any_conf_read?
|
|
|
|
|
;
|
|
|
|
|
|
1999-03-09 14:06:55 +00:00
|
|
|
\ ***** read-conf
|
|
|
|
|
\
|
|
|
|
|
\ Read a configuration file, whose name was specified on the command
|
|
|
|
|
\ line, if interpreted, or given on the stack, if compiled in.
|
|
|
|
|
|
|
|
|
|
: (read-conf) ( addr len -- )
|
2009-01-05 20:09:54 +00:00
|
|
|
conf_files string=
|
1999-03-09 14:06:55 +00:00
|
|
|
include_conf_files \ Will recurse on new loader_conf_files definitions
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
: read-conf ( <filename> | addr len -- ) ( throws: abort & user-defined )
|
|
|
|
|
state @ if
|
|
|
|
|
\ Compiling
|
|
|
|
|
postpone (read-conf)
|
|
|
|
|
else
|
|
|
|
|
\ Interpreting
|
|
|
|
|
bl parse (read-conf)
|
|
|
|
|
then
|
|
|
|
|
; immediate
|
|
|
|
|
|
2009-01-05 20:09:54 +00:00
|
|
|
\ show, enable, disable, toggle module loading. They all take module from
|
|
|
|
|
\ the next word
|
1999-04-24 17:25:35 +00:00
|
|
|
|
2009-01-05 20:09:54 +00:00
|
|
|
: set-module-flag ( module_addr val -- ) \ set and print flag
|
|
|
|
|
over module.flag !
|
|
|
|
|
dup module.name strtype
|
|
|
|
|
module.flag @ if ." will be loaded" else ." will not be loaded" then cr
|
1999-04-24 17:25:35 +00:00
|
|
|
;
|
|
|
|
|
|
2009-01-05 20:09:54 +00:00
|
|
|
: enable-module find-module ?dup if true set-module-flag then ;
|
|
|
|
|
|
|
|
|
|
: disable-module find-module ?dup if false set-module-flag then ;
|
|
|
|
|
|
|
|
|
|
: toggle-module find-module ?dup if dup module.flag @ 0= set-module-flag then ;
|
1999-04-24 17:25:35 +00:00
|
|
|
|
1999-03-09 14:06:55 +00:00
|
|
|
\ ***** show-module
|
|
|
|
|
\
|
|
|
|
|
\ Show loading information about a module.
|
|
|
|
|
|
2009-01-05 20:09:54 +00:00
|
|
|
: show-module ( <module> -- ) find-module ?dup if show-one-module then ;
|
1999-03-09 14:06:55 +00:00
|
|
|
|
|
|
|
|
\ Words to be used inside configuration files
|
|
|
|
|
|
|
|
|
|
: retry false ; \ For use in load error commands
|
|
|
|
|
: ignore true ; \ For use in load error commands
|
|
|
|
|
|
|
|
|
|
\ Return to strict forth vocabulary
|
|
|
|
|
|
2000-09-16 21:04:49 +00:00
|
|
|
: #type
|
|
|
|
|
over - >r
|
|
|
|
|
type
|
|
|
|
|
r> spaces
|
|
|
|
|
;
|
|
|
|
|
|
|
|
|
|
: .? 2 spaces 2swap 15 #type 2 spaces type cr ;
|
|
|
|
|
|
|
|
|
|
: ?
|
|
|
|
|
['] ? execute
|
|
|
|
|
s" boot-conf" s" load kernel and modules, then autoboot" .?
|
|
|
|
|
s" read-conf" s" read a configuration file" .?
|
|
|
|
|
s" enable-module" s" enable loading of a module" .?
|
|
|
|
|
s" disable-module" s" disable loading of a module" .?
|
|
|
|
|
s" toggle-module" s" toggle loading of a module" .?
|
|
|
|
|
s" show-module" s" show module load data" .?
|
|
|
|
|
;
|
|
|
|
|
|
1999-03-09 14:06:55 +00:00
|
|
|
only forth also
|
1999-05-14 18:59:27 +00:00
|
|
|
|
