Searched hist:65630 (Results 1 - 3 of 3) sorted by relevance
| /freebsd-10.1-release/sys/boot/forth/ | ||
| H A D | support.4th | diff 65630 Sat Sep 09 02:52:34 MDT 2000 dcs 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.) |
| H A D | loader.4th | diff 65630 Sat Sep 09 02:52:34 MDT 2000 dcs 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.) |
| H A D | loader.conf | diff 65630 Sat Sep 09 02:52:34 MDT 2000 dcs 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.) |
Completed in 117 milliseconds