With autodetection turned on, hitting the filesystem everytime we need to
calculate choices for the kernel carousel is kind of slow. Cache once on the
first listing and reload it anytime the config is reloaded in case any of
the loader.conf(5) changes that affect this (kernel, kernels,
kernels_autodetect) have changed. This also picks up the case where we've
changed currdev and the autodetected kernels could change.
cli_execute was changed to return the status, cascade that to
cli_execute_unparsed.
This fixes a lot of false "Failed to execute" errors following r330620; no
failures actually occurred, but [module]_error would've then promptly
executed (and also "failed")
These tend to have less coverage in other places and they don't have
defaults as of yet, so mention them here:
- fdt_overlays
- kernels_autodetect (lualoader only)
This applies to:
- exec
- [module]_before
- [module]_error
- [module]_after
Before this commit, these used loader.perform to execute them as a pure,
unsalted loader command. This means that they were not able to take
advantage of any Lua-salted loader commands, like boot and autoboot, or pure
Lua loader commands (functions attached to the 'cli' module).
They now have access to the full arsenal, just shy of being able to execute
arbitrary Lua.
loader.interpret should not be used for executing loader commands from an
untrusted source (e.g. environment vars) as it will allow execution of
arbitrary Lua. Replace it with a call to the recently introduced
cli_execute_unparsed, which parses it out as a loader command and then
dispatches it as a loader command. This effectively filters out arbitrary
Lua.
This will be used for scenarios where the command to execute is coming in
via the environment (from, for example, loader.conf(5)) and is thus not
necessarily trusted.
cli_execute_unparsed will immediately be used for handling
module_{before,after,error} as well as menu_timeout_command. We still want
to offer these variables the ability to execute Lua-intercepted loader
commands, but we don't want them to be able to execute arbitrary Lua.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D14580
testmain is a userland application intended to be built with standard
headers and whatnot, which we broke.
Fix it by having the testmain build clobber cflags, reducing it to just the
set of defines/includes it needs to build.
Discussed with: imp
MFC after: 3 days
Back when I "fixed" the loading of kernel/modules to be deferred until
booting, I inadvertently broke the ability to manually load a set of kernels
and modules in case of something bad having happened. lualoader would
instead happily load whatever is specified in loader.conf(5) and go about
the boot, leading to a panic loop as you try to rediscover a way to stop the
panicky efirt module from loading and fail miserably.
Reported by: me, sadly
than a pointer to Open Firmware by default. This eliminates a number of
potentially unsafe calls to firmware from the kernel and provides better
performance.
This feature is meant to be expanded until it is on by default
unconditionally and, ideally, we can then garbage-collect the
nightmare pile of hacks required to call into Open Firmware from a live
kernel.
Reviewed by: jhibbits
loader.command(...) will return whatever the executed function returns, so
follow suit and return whatever loader.command() returned or whatever the
Lua function returns.
the powerpc/ subdirectory. These have never used by SPARC and we have
no other (and almost certainly will have no other) Open Firmware platforms.
This makes the directory structure simpler and lets us avoid some
cargo-cult MI patterns on code that is, and always was,
architecture-specific.
- All of our default positions were offset from forth
- Our menu frame size was smaller than in forth
- Logo/brand drawing had an off-by-one, drawing one column lower on the
screen than they should have been.
- While here, switch a print() to printc() as it's expected that logos may
contain color and other escpae sequences that we'll need to honor.
It may be set to "left" or "right" -- any other value will cause the title
to be centered.
I've chosen to position these things just inside the vertical borders,
rather than overlapping the corners. This is an arbitrary choice and easily
amendable if this looks terrible.
This allows lua to pass back a command string to be executed as if it were
typed at the loader prompt- loader tries to execute the string first as pure
lua, then parses it and gives lua a chance to intercept before it tries to
execute it itself.
This will be used to implement menu_timeout_command, among other things,
which *should* be used to execute basic loader commands independent of the
chosen interpreter.
Rather than before the menu is drawn. The drawer is going to reset the
crusor position as soon as it draws anything anyways, so doing it before
serves no purpose. Setting it after is needed so we don't clobber the menu
when we start booting.
printc does not need the features or the overhead of printf. It does not
take formatting strings, and it pipes the single string argument through an
"%s" format.
Instead, use putc directly. This pipes the string through in its entirety as
a series of 'unsigned char's, generally straight to the console emulator.
Discussed with: tsoome
r330282 registered loader.printc as printc, so use it instead. This makes
sense for a couple reasons, the major point being that it reads a little bit
easier and pairs nicely with the global 'print'.
Similar cases can not really be made for other loader.* functions as most of
them are either highly specific to our use-case or usually available in
other modules, such as `os`. printc does not have a standard implementation
in the Lua world(*), so we have a little more leeway with it, and it's kind
of a special case of the globally available 'print'.
(*) I've been in the Lua world for all of two weeks, so this could be wrong.
- Add drawer.frame_styles to map out the kinds of characters we need for the
different loader_menu_frame values
- Respect loader_menu_frame, default to double[*]
- (imp) Use loader.printc instead of print- print adds a newline to the
output, which is not the right thing we want to be doing.
- (imp) Draw horizontal frames a little more efficiently- setting the cursor
after every line segment is horribly inefficient, especially on serial
consoles. Halve the number of characters written at the expense of an
additional loop to draw the bottom frame, which is likely more efficient
in the long run for some of less ideal scenarios.
[*] menu.4th(8) claims that the default here was single, but unset
loader_menu_frame yielded double and we didn't have any overrides in the
default loader.conf(5), so double it is.
Distribution will be done after all of the lualoader manpages are created.
Reviewed by: rpokala
Differential Revision: https://reviews.freebsd.org/D14480
Distribution will be done after all of the lualoader manpages are created.
Reviewed by: rpokala
Differential Revision: https://reviews.freebsd.org/D14479
to fix the memory leak that I introduced in r328426. Instead of
trying to clear up the possible memory leak in all the clients, I
ensure that it gets cleaned up in the source (e.g., ffs_sbget ensures
that memory is always freed if it returns an error).
The original change in r328426 was a bit sparse in its description.
So I am expanding on its description here (thanks cem@ and rgrimes@
for your encouragement for my longer commit messages).
In preparation for adding check hashing to superblocks, r328426 is
a refactoring of the code to get the reading/writing of the superblock
into one place. Unlike the cylinder group reading/writing which
ends up in two places (ffs_getcg/ffs_geom_strategy in the kernel
and cgget/cgput in libufs), I have the core superblock functions
just in the kernel (ffs_sbfetch/ffs_sbput in ffs_subr.c which is
already imported into utilities like fsck_ffs as well as libufs to
implement sbget/sbput). The ffs_sbfetch and ffs_sbput functions
take a function pointer to do the actual I/O for which there are
four variants:
ffs_use_bread / ffs_use_bwrite for the in-kernel filesystem
g_use_g_read_data / g_use_g_write_data for kernel geom clients
ufs_use_sa_read for the standalone code (stand/libsa/ufs.c
but not stand/libsa/ufsread.c which is size constrained)
use_pread / use_pwrite for libufs
Uses of these interfaces are in the UFS filesystem, geoms journal &
label, libsa changes, and libufs. They also permeate out into the
filesystem utilities fsck_ffs, newfs, growfs, clri, dump, quotacheck,
fsirand, fstyp, and quot. Some of these utilities should probably be
converted to directly use libufs (like dumpfs was for example), but
there does not seem to be much win in doing so.
Tested by: Peter Holm (pho@)
One does not simply convert to SUBDIR.yes in stand without making everything
else in the affected files SUBDIR.yes -- there are better ways to do this.
Use SUBDIR.${MK_*} where appropriate. r330248 eliminated most of the
offenders, sweep the rest under the rug.
Differential Revision: https://reviews.freebsd.org/D14545
Makefile.${MACHINE_ARCH} and remove the now-empty files. Generate the
*32 directories on the necessary architectures (well, currently only
amd64) on the fly. Remove LOADER_EFI variable and co-locate it with
EFI.
Differential Review: https://reviews.freebsd.org/D14546
Rather than hardcoding these things. This could lead to some form of loader
localization later, but the main goal at the moment is to get a clear view
of the strings we're outputting and strive to use more string.format() and
less wild concatenation all over the place.
We've included an extra '0' in there (which might get removed later, but
it's maintained for the moment for legacy purposes) which oftentimes
indicate that the following number should be treated as octal. This is not
the case, so note that to prevent future confusion (of myself and others).
Our module bits ended up more stable than I anticipated, so this turns out
to be no longer useful.
If things like this need to come back, we should do it in a separate 'debug'
module to serve as a collection of debugging aides. As a rule, this 'debug'
module would *not* be allowed as a requirement of any other modules in-tree.
- Add screen.default_x and screen.default_y to determine where
screen.defcursor resets the cursor to.
- Use screen.setcursor in screen.defcursor instead of rewriting the escape
sequence.
- Use screen.default_y when resetting the cursor after writing the new
twiddle character, add a comment verbally describing the position just in
case.
It worked on my test setup, but is clearly non-functional on others.
Further examination of check-password.4th showed that it actually reset the
cursor to 0,25 every time and overwrote the previous password prompt. Do
that, and also clear the "Incorrect Password" text if the correct password
gets entered.
twiddle_pos didn't need to be a module-scope local, since it's going to get
reset with every read anyways- it was left-over from other things.
screen.movecursor with a y=-1 setting was from a test of movecursor,
resulting in the twiddle characters being drawn going up the console and
looking quite funky.
This gives some form of feedback while typing, and matches-(ish*) Forth
behavior. The cursor generally rests two column after the password prompt,
then the twiddle is drawn three columns later and the cursor reset to
resting position after being drawn.
I've removed the note about re-evaluating it for security considerations and
instead set it up as a module-local variable that we can set later depending
on environment or something. It's set to false with no chance of changing at
the moment.
*As close as I can tell from reading check-password.4th, because I don't
have an easy test (or deployed) setup for forth loader to check how close
it is. Please do mention if it's not close enough.
