freebsd-dev/sys/boot/forth/loader.4th

253 lines
6.6 KiB
Plaintext
Raw Normal View History

\ Copyright (c) 1999 Daniel C. Sobral <dcs@FreeBSD.org>
\ Copyright (c) 2011-2015 Devin Teske <dteske@FreeBSD.org>
1999-03-09 14:06:55 +00:00
\ 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
only forth definitions
2000-06-14 19:39:31 +00:00
s" arch-i386" environment? [if] [if]
s" loader_version" environment? [if]
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
Add an echo to say we're "Booting..." when the overloaded "boot" Ficl word is executed to better differentiate between loader-specific errors and kernel- specific errors (if ever any of either). This type of functionality hasn't been required before the introduction of the advanced menu system (r222417). Adding this functionality will help different- iate errors at the loader-level such as a BTX halt caused by heap exhaustion and errors that may be involved with executing the kernel (wrong architecture for example). A user can learn that messages before "Booting..." are related to the loader(8) environment and it's Forth-ilk, while those after are not related to loader(8) -- the point that loader(8) has ``left the building''. This patch also includes a man-page update to color.4th(8) as the color logic moves to a lower-level (from being included by beastie.4th to being included by loader.4th). After noticing a delay between execution of the overloaded "boot" FICL word and the display of text on-screen, gcooper confirmed that the introduction of a builtin memory test (disabled by adding hw.memtest.tests="0" to loader.conf(5)) was the cause of the delay. This patch adds an echo to produce "Booting..." when the overloaded "boot" word is executed (this includes from the interactive command-prompt on all arches, from the menu system on arches that run the beastie menu, and even those arches that run the menu but disable it by setting beastie_disable="YES" in loader.conf(5)). When loader_color="YES" in loader.conf(5), the same message is produced but in white text on a blue background (only the letters produced have this background -- opposed to perhaps the entire line).
2012-10-08 23:02:35 +00:00
include /boot/color.4th
include /boot/delay.4th
include /boot/check-password.4th
1999-03-09 14:06:55 +00:00
only forth definitions
: bootmsg ( -- )
loader_color? dup ( -- bool bool )
if 7 fg 4 bg then
." Booting..."
if me then
cr
;
: try-menu-unset
\ menu-unset may not be present
s" beastie_disable" getenv
dup -1 <> if
s" YES" compare-insensitive 0= if
exit
then
else
drop
then
s" menu-unset"
sfind if
execute
else
drop
then
s" menusets-unset"
sfind if
execute
else
drop
then
;
only forth also support-functions also builtins definitions
: boot
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
\ Unload only if a path was passed
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
s" kernelname" getenv? if ( a kernel has been loaded )
try-menu-unset
bootmsg 1 boot exit
then
load_kernel_and_modules
?dup if exit then
try-menu-unset
bootmsg 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
s" kernelname" getenv? if ( a kernel has been loaded )
try-menu-unset
bootmsg 1 boot exit
then
load_kernel_and_modules
?dup if exit then
try-menu-unset
bootmsg 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
load_kernel_and_modules
?dup 0= if bootmsg 0 1 boot then
;
\ ***** boot-conf
\
\ Prepares to boot as specified by loaded configuration files.
: boot-conf
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
load_kernel_and_modules
?dup 0= if 0 1 autoboot then
1999-03-09 14:06:55 +00:00
;
also forth definitions previous
builtin: boot
builtin: boot-conf
only forth definitions also support-functions
1999-03-09 14:06:55 +00:00
\ ***** start
\
\ Initializes support.4th global variables, sets loader_conf_files,
\ processes conf files, and, if any one such file was succesfully
\ read to the end, loads kernel and modules.
1999-03-09 14:06:55 +00:00
: start ( -- ) ( throws: abort & user-defined )
s" /boot/defaults/loader.conf" initialize
include_conf_files
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
s" loader_delay" getenv -1 = if
loader: implement multiboot support for Xen Dom0 Implement a subset of the multiboot specification in order to boot Xen and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot implementation is tailored to boot Xen and FreeBSD Dom0, and it will most surely fail to boot any other multiboot compilant kernel. In order to detect and boot the Xen microkernel, two new file formats are added to the bootloader, multiboot and multiboot_obj. Multiboot support must be tested before regular ELF support, since Xen is a multiboot kernel that also uses ELF. After a multiboot kernel is detected, all the other loaded kernels/modules are parsed by the multiboot_obj format. The layout of the loaded objects in memory is the following; first the Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to long mode by itself), after that the FreeBSD kernel is loaded as a RAW file (Xen will parse and load it using it's internal ELF loader), and finally the metadata and the modules are loaded using the native FreeBSD way. After everything is loaded we jump into Xen's entry point using a small trampoline. The order of the multiboot modules passed to Xen is the following, the first module is the RAW FreeBSD kernel, and the second module is the metadata and the FreeBSD modules. Since Xen will relocate the memory position of the second multiboot module (the one that contains the metadata and native FreeBSD modules), we need to stash the original modulep address inside of the metadata itself in order to recalculate its position once booted. This also means the metadata must come before the loaded modules, so after loading the FreeBSD kernel a portion of memory is reserved in order to place the metadata before booting. In order to tell the loader to boot Xen and then the FreeBSD kernel the following has to be added to the /boot/loader.conf file: xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga" xen_kernel="/boot/xen" The first argument contains the command line that will be passed to the Xen kernel, while the second argument is the path to the Xen kernel itself. This can also be done manually from the loader command line, by for example typing the following set of commands: OK unload OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga OK load kernel OK load zfs OK load if_tap OK load ... OK boot Sponsored by: Citrix Systems R&D Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D517 For the Forth bits: Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
load_xen_throw
load_kernel
load_modules
else
drop
." Loading Kernel and Modules (Ctrl-C to Abort)" cr
s" also support-functions" evaluate
loader: implement multiboot support for Xen Dom0 Implement a subset of the multiboot specification in order to boot Xen and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot implementation is tailored to boot Xen and FreeBSD Dom0, and it will most surely fail to boot any other multiboot compilant kernel. In order to detect and boot the Xen microkernel, two new file formats are added to the bootloader, multiboot and multiboot_obj. Multiboot support must be tested before regular ELF support, since Xen is a multiboot kernel that also uses ELF. After a multiboot kernel is detected, all the other loaded kernels/modules are parsed by the multiboot_obj format. The layout of the loaded objects in memory is the following; first the Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to long mode by itself), after that the FreeBSD kernel is loaded as a RAW file (Xen will parse and load it using it's internal ELF loader), and finally the metadata and the modules are loaded using the native FreeBSD way. After everything is loaded we jump into Xen's entry point using a small trampoline. The order of the multiboot modules passed to Xen is the following, the first module is the RAW FreeBSD kernel, and the second module is the metadata and the FreeBSD modules. Since Xen will relocate the memory position of the second multiboot module (the one that contains the metadata and native FreeBSD modules), we need to stash the original modulep address inside of the metadata itself in order to recalculate its position once booted. This also means the metadata must come before the loaded modules, so after loading the FreeBSD kernel a portion of memory is reserved in order to place the metadata before booting. In order to tell the loader to boot Xen and then the FreeBSD kernel the following has to be added to the /boot/loader.conf file: xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga" xen_kernel="/boot/xen" The first argument contains the command line that will be passed to the Xen kernel, while the second argument is the path to the Xen kernel itself. This can also be done manually from the loader command line, by for example typing the following set of commands: OK unload OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga OK load kernel OK load zfs OK load if_tap OK load ... OK boot Sponsored by: Citrix Systems R&D Reviewed by: jhb Differential Revision: https://reviews.freebsd.org/D517 For the Forth bits: Submitted by: Julien Grall <julien.grall AT citrix.com>
2015-01-15 16:27:20 +00:00
s" set delay_command='load_xen_throw load_kernel load_modules'" evaluate
s" set delay_showdots" evaluate
delay_execute
then
1999-03-09 14:06:55 +00:00
then
;
\ ***** 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
include_nextboot_file
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 -- )
This patch introduces a number of simplifications to the Forth functions used in the bootloader. The goal is to make the code more readable and smaller (especially because we have size issues in the loader's environment). High level description of the changes: + define some string manipulation functions to improve readability; + create functions to manipulate module descriptors, removing some duplicated code; + rename the error codes to ESOMETHING; + consistently use set_environment_variable (which evaluates $variables) when interpreting variable=value assignments; I have tested the code, but there might be code paths that I have not traversed so please let me know of any issues. Details of this change: --- loader.4th --- + add some module operators, to remove duplicated code while parsing module-related commands: set-module-flag enable-module disable-module toggle-module show-module --- pnp.4th --- + move here the definition related to the pnp devices list, e.g. STAILQ_* , pnpident, pnpinfo --- support.4th --- + rename error codes to capital e.g. ENOMEM EFREE ... and do obvious changes related to the renaming; + remove unused structures (those relevant to pnp are moved to pnp.4th) + various string functions - strlen removed (it is an internal function) - strchr, defined as the C function - strtype -- type a string to output - strref -- assign a reference to the string on the stack - unquote -- remove quotes from a string + remove reset_line_buffer + move up the 'set_environment_variable' function (which now uses the interpreter, so $variables are evaluated). Use the function in various places + add a 'test_file function' for debugging purposes MFC after: 4 weeks
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
This patch introduces a number of simplifications to the Forth functions used in the bootloader. The goal is to make the code more readable and smaller (especially because we have size issues in the loader's environment). High level description of the changes: + define some string manipulation functions to improve readability; + create functions to manipulate module descriptors, removing some duplicated code; + rename the error codes to ESOMETHING; + consistently use set_environment_variable (which evaluates $variables) when interpreting variable=value assignments; I have tested the code, but there might be code paths that I have not traversed so please let me know of any issues. Details of this change: --- loader.4th --- + add some module operators, to remove duplicated code while parsing module-related commands: set-module-flag enable-module disable-module toggle-module show-module --- pnp.4th --- + move here the definition related to the pnp devices list, e.g. STAILQ_* , pnpident, pnpinfo --- support.4th --- + rename error codes to capital e.g. ENOMEM EFREE ... and do obvious changes related to the renaming; + remove unused structures (those relevant to pnp are moved to pnp.4th) + various string functions - strlen removed (it is an internal function) - strchr, defined as the C function - strtype -- type a string to output - strref -- assign a reference to the string on the stack - unquote -- remove quotes from a string + remove reset_line_buffer + move up the 'set_environment_variable' function (which now uses the interpreter, so $variables are evaluated). Use the function in various places + add a 'test_file function' for debugging purposes MFC after: 4 weeks
2009-01-05 20:09:54 +00:00
\ show, enable, disable, toggle module loading. They all take module from
\ the next word
This patch introduces a number of simplifications to the Forth functions used in the bootloader. The goal is to make the code more readable and smaller (especially because we have size issues in the loader's environment). High level description of the changes: + define some string manipulation functions to improve readability; + create functions to manipulate module descriptors, removing some duplicated code; + rename the error codes to ESOMETHING; + consistently use set_environment_variable (which evaluates $variables) when interpreting variable=value assignments; I have tested the code, but there might be code paths that I have not traversed so please let me know of any issues. Details of this change: --- loader.4th --- + add some module operators, to remove duplicated code while parsing module-related commands: set-module-flag enable-module disable-module toggle-module show-module --- pnp.4th --- + move here the definition related to the pnp devices list, e.g. STAILQ_* , pnpident, pnpinfo --- support.4th --- + rename error codes to capital e.g. ENOMEM EFREE ... and do obvious changes related to the renaming; + remove unused structures (those relevant to pnp are moved to pnp.4th) + various string functions - strlen removed (it is an internal function) - strchr, defined as the C function - strtype -- type a string to output - strref -- assign a reference to the string on the stack - unquote -- remove quotes from a string + remove reset_line_buffer + move up the 'set_environment_variable' function (which now uses the interpreter, so $variables are evaluated). Use the function in various places + add a 'test_file function' for debugging purposes MFC after: 4 weeks
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
;
This patch introduces a number of simplifications to the Forth functions used in the bootloader. The goal is to make the code more readable and smaller (especially because we have size issues in the loader's environment). High level description of the changes: + define some string manipulation functions to improve readability; + create functions to manipulate module descriptors, removing some duplicated code; + rename the error codes to ESOMETHING; + consistently use set_environment_variable (which evaluates $variables) when interpreting variable=value assignments; I have tested the code, but there might be code paths that I have not traversed so please let me know of any issues. Details of this change: --- loader.4th --- + add some module operators, to remove duplicated code while parsing module-related commands: set-module-flag enable-module disable-module toggle-module show-module --- pnp.4th --- + move here the definition related to the pnp devices list, e.g. STAILQ_* , pnpident, pnpinfo --- support.4th --- + rename error codes to capital e.g. ENOMEM EFREE ... and do obvious changes related to the renaming; + remove unused structures (those relevant to pnp are moved to pnp.4th) + various string functions - strlen removed (it is an internal function) - strchr, defined as the C function - strtype -- type a string to output - strref -- assign a reference to the string on the stack - unquote -- remove quotes from a string + remove reset_line_buffer + move up the 'set_environment_variable' function (which now uses the interpreter, so $variables are evaluated). Use the function in various places + add a 'test_file function' for debugging purposes MFC after: 4 weeks
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-03-09 14:06:55 +00:00
\ ***** show-module
\
\ Show loading information about a module.
This patch introduces a number of simplifications to the Forth functions used in the bootloader. The goal is to make the code more readable and smaller (especially because we have size issues in the loader's environment). High level description of the changes: + define some string manipulation functions to improve readability; + create functions to manipulate module descriptors, removing some duplicated code; + rename the error codes to ESOMETHING; + consistently use set_environment_variable (which evaluates $variables) when interpreting variable=value assignments; I have tested the code, but there might be code paths that I have not traversed so please let me know of any issues. Details of this change: --- loader.4th --- + add some module operators, to remove duplicated code while parsing module-related commands: set-module-flag enable-module disable-module toggle-module show-module --- pnp.4th --- + move here the definition related to the pnp devices list, e.g. STAILQ_* , pnpident, pnpinfo --- support.4th --- + rename error codes to capital e.g. ENOMEM EFREE ... and do obvious changes related to the renaming; + remove unused structures (those relevant to pnp are moved to pnp.4th) + various string functions - strlen removed (it is an internal function) - strchr, defined as the C function - strtype -- type a string to output - strref -- assign a reference to the string on the stack - unquote -- remove quotes from a string + remove reset_line_buffer + move up the 'set_environment_variable' function (which now uses the interpreter, so $variables are evaluated). Use the function in various places + add a 'test_file function' for debugging purposes MFC after: 4 weeks
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
: #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" .?
s" try-include" s" try to load/interpret files" .?
;
: try-include ( -- ) \ see loader.4th(8)
['] include ( -- xt ) \ get the execution token of `include'
catch ( xt -- exception# | 0 ) if \ failed
LF parse ( c -- s-addr/u ) 2drop \ advance >in to EOL (drop data)
\ ... prevents words unused by `include' from being interpreted
then
; immediate \ interpret immediately for access to `source' (aka tib)
only forth definitions