On Wed, Feb 21, 2018 at 8:55 AM, Warner Losh <imp_at_bsdimp.com> wrote: > > > On Wed, Feb 21, 2018 at 6:58 AM, Kyle Evans <kevans_at_freebsd.org> wrote: >> >> On Wed, Feb 21, 2018 at 4:43 AM, Juan Ramón Molina Menor <listjm_at_club.fr> >> wrote: >> > Le 20/02/2018 à 22:45, Kyle Evans a écrit : >> >> >> >> On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor >> >> <listjm_at_club.fr> >> >> wrote: >> >>> >> >>> [... snip ...] >> >>> >> >>> Moreover, the "boot [kernel]" loader command does not work: >> >>> >> >>> OK ls /boot/kernel.old/kernel >> >>> /boot/kernel.old/kernel >> >>> OK boot kernel.old >> >>> Command failed >> >>> OK boot /boot/kernel.old/kernel >> >>> Command failed >> >>> OK boot kernel >> >>> Command failed >> >>> >> >>> On the other hand, just "boot" works. >> >>> >> >> >> >> This part should work as expected as of r329674, so please give that a >> >> shot. I'm still trying to see if I can reproduce your box drawing >> >> problem. >> >> >> >> Thanks, >> >> >> >> Kyle Evans >> >> >> > >> > Thanks Kyle. >> > >> > boot command works now. There is though a somewhat strangely formulated >> > messages when trying to load an non-existent kernel: >> > >> > OK boot fake >> > Failed to load kernel ’fake’ >> > Failed to load any kernel >> > can’t load ’kernel’ >> > >> > The two last lines are odd: Did the loader try to load a fallback kernel >> > and >> > failed? That would explain the ’kernel’ name in quotes, but I have such >> > a >> > kernel… Also, just nitpicking, but "can’t" should be capitalized. >> >> (CC'ing Rod, since he also commented on this) >> >> I'm only directly responsible for the first two messages. =) I've >> removed the second one, though, since it was a carry-over from when it >> would try to load the selected kernel and then some default kernel >> that might be in your module_path. >> >> We can look at changing "can't load 'kernel'" to capitalize and remove >> the contraction, but that's common loader stuff and should've also >> been displayed for the same Forth scenario. >> >> > Then, I have just remembered why I was seeing a higher resolution menu >> > before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new >> > loader is not implementing the inclusion of this file, because I can >> > change >> > the gop mode in the loader with 'gop set [0-3]'. >> > >> >> Oy. This is actually a Forth file, so we can't really maintain all of >> the functionality that would have been allowed there. Technically, >> things like this should probably either appear in your loader.conf(5) >> in the form of 'exec="gop set 3"' to be applied when loader.conf(5) is >> read, or we should provide some other means of running pure loader >> command scripts at different points in the loader sequence. (CC >> Warner, because he probably has thoughts about this latter idea) > > > While loader.rc is FORTH, it's contrived FORTH designed to look like command > line interaction. While some crazy people like me have actual forth in > these, most do not, really (apart from the include /boot/XXX.4th lines, that > is, which could be filtered). > > We have two choices here: Try to provide some level of compatibility shims, > or provide a new way to say these things in Lua. > > In the original SoC code, loader.lua lived in /boot and looked to be > something that people could modify. We likely need to do something similar. > loader.lua right now has nothing but were in the forth world called > 'include' and then very similar commands to the forth loader.rc. Perhaps the > right answer is to move cli_execute out of /boot/lua/loader.lua, move that > file up, and add the try-include functionality to try to include a > loader.local.lua. Then we could tell people to move to the Lua syntax way of > doing things. We'd have to hunt down all the hacks like this, but that > wouldn't be terrible. Bonus points if we could convert the common ones > either to lua code automatically, or to loader.conf variables. We have something like this that I added yesterday in r329692, but named a little bit differently ("local.lua", "local module"). Mostly added because I've been using it to locally add test menu options and writing some of the documentation for how to hook into our new lua system to do things, and it was getting tiresome having to manually revert those bits in loader.lua when I wanted to make changes to the in-tree loader.lua. We'd basically rename this to loader.local.lua to match more closely to current convention, move "cli_execute" out to either core.lua or maybe it and the boot commands are worthy of their own "cli" module, then be happy. > This specific example should have always been a loader.conf variable (and > not an exec). While the gop command is useful, the loader should have, as > part of it's forth sequence, had something that would set the GOP mode if > the uefi_gop_mode loader.conf variable was set (I get why that wasn't done > that way in the forth loader, insert rant of Fear of FORTH here). So we > should 'unkludge' it, have Lua loader grok uefi_gop_mode and maybe a few > other things that are simple settings to make it easier for users to set > this stuff up and start to move away from the FoF kludges that we've > accumulated. A new loader.conf variable would also allow coexistence of the > two loaders, which will be further helped with some patches I have to the > build system coming soon. Right, this seemed like something worthy of its own loader.conf(5) variable. I didn't patch that idea, though, because I didn't necessarily want to write the Forth handling of it. =)Received on Wed Feb 21 2018 - 14:37:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:15 UTC