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.
There are some _write callbacks left only returning EROFS, replace them
by null_write. return EROFS from null_write().
Reviewed by: cem, imp, kan
Differential Revision: https://reviews.freebsd.org/D14523
Current timeout behavior is to progress in timeout values from MINTMO to
MAXTMO in MINTMO steps before finally timing out. This results in a fairly
long time before operations finally timeout, which may not be ideal for some
use-cases.
Add MAXWAIT that may be configured along with MINTMO/MAXTMO. If we attempt
to start our send/recv cycle over again but MAXWAIT > 0 and MAXWAIT seconds
have already passed, then go ahead and timeout.
This is intended for those that just want to say "timeout after 180 seconds"
rather than calculate and tweak MINTMO/MAXTMO to get their desired timeout.
The default is 0, or "progress from MINTMO to MAXTMO with no exception."
This has been modified since review to allow for it to be defined via CFLAGS
and doing appropriate error checking. Future work may add some Makefile foo
to respect LOADER_NET_MAXWAIT if it's specified in the environment and pass
it in as MAXWAIT accordingly.
Reviewed by: imp, sbruno, tsoome (all previous version)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14389
This is motivated by a want to reduce heap usage if the menu is being
skipped. Currently, the menu module must be loaded regardless of whether
it's being skipped or not, which adds a cool ~50-100KB worth of memory
usage.
Move the menu skip logic out to core (and remove a debug print), then check
in loader.lua if we should be skipping the menu and avoid loading the menu
module entirely if so. This keeps our memory usage below ~115KB for a boot
with the menu stripped.
Also worth noting: with this change, we no longer explicitly invoke autoboot
if we're skipping the menu. Instead, we let the standard loader behavior
apply: try to autoboot if we need to, then drop to a loader prompt if not or
if the autoboot sequence is interrupted. The only thing we still handle
before dropping to the loader autoboot sequence is loadelf(), so that we can
still apply any of our kernel loading behavior.
screen was also guilty of not-so-great argument names, but it was also
guilty of handling color sequences on its own. Change those bits to using
the color module instead.
As a side note, between color and screen, I'm not 100% sure that returning
the color_value is the right thing to do if we won't generate the escape
sequences. This should be re-evaluated at a later time, and they should
likely return nil instead.
Instead of a single-letter parameter ('m'), use something a little more
descriptive and meaningful: 'menudef' ("menu definition") -- these functions
expect to be passed a menudef, so call it what it is.
While here, throw an assertion in that we have a handler for the selected
menu item. This is more of a debugging aide so that it's more obvious when
one is testing a menudef that they've added an entry item that we don't
handle.
This is an improvement over the past behavior of ignoring the unknown menu
entry.
Remove almost all of the _load=XXX options (kept only those relevant
to splash screens, since there were other settings).
Remove the excessively cutesy comment blocks.
Remove excessive comments and replace with similar content
Remove gratuitous blank lines (while leaving some)
We have too many modules to list them all here. There's no purpose in
doing so and it's a giant hassle to maintain. In addition the extra
~500 lines slow this down on small platforms. It slowed it down
so much small platforms forked, which caused other issues...
This is a compromise between those two extremes.
We really only need one loader.conf. The other loader.conf was created
because the current one took forever to parse in FORTH. That will be
fixed in the next commit.
For directories that don't many anything, add NO_OBJ=t just before we
include bsd.init.mk. This prevents them from creating an OBJ
directory. In addition, prevent defs.mk from creating the machine
related links in these cases. They aren't needed and break, at least
on stable, the read-only src tree build.
This cleans up the odd approach to menu drawing. Instead of tracking
validity, we track the menu that was drawn on the screen. Whenever we draw a
menu, we'll set this to that menu.
Anything that invalidates the screen should go ahead and trigger an explicit
redraw, rather than finding a wy to set screen_invalid.
The currently drawn menu is then reset in menu.run as we exit the menu
system, so that dropping to the loader prompt or leaving menu.run() will
just behave as expected without doing redundant work every time we leave a
menu.
In the common case, this will effectively do nothing as the menu will get
redrawn as we leave submenus regardless of whether the screen has been
marked invalid or not
However, upon escape to the loader prompt, one could do either of the
following to re-enter the menu system:
-- Method 1
require('menu').run()
-- Method 2
require('menu').process(menu.default)
With method 1, the menu will get redrawn anyways as we do this before
autoboot checking upon entry. With method 2, however, the menu will not be
redrawn without this invalidation.
Both methods are acceptable for re-entering the menu system, although the
latter method in the local module for processing new and interesting menus
is more expected.
cli_execute is likely the only exception that we should make, due to it
being a global. We don't really need other globals, so this won't really end
up an epidemic.
There's no reason for autoboot handling to be mixed in with menu processing.
It is a distinct process that should only be done once when entering the
menu system.
menu.process has been modified to take an initial keypress to process and to
only draw the screen initially if it's been invalidated. The keypress is
kind of a kludge, although it could be argued to be a potentially useful
kludge if there are other processes that may need to feed a keypress into
the menu system.
In general, every menu redraw is going to require a screen clear and cursor
reset. Each redraw also has the potential to invalidate the alias table, so
we move the alias table being used out into a module variable. This allows
third party consumers to also inspect or update the alias table if they need
to.
While here, stop searching the alias table once we've found a match.
This is driven by an urge to separate out the bits that really only need to
happen when the menu system starts up. Key points:
- menu.process now does the bulk of menu handling. It retains autoboot
handling for dubious reasons, and it no longer accepts a 'nil' menu to
process as 'the default'. Its return value is insignificant.
- The MENU_SUBMENU handler now returns nothing. If menu.process has exited,
then we continue processing menu items on the parent menu as expected.
- menu.run is now the entry point of the menu system. It checks whether the
menu should be skipped, processes the default menu, then returns.
These indices were assigned the same values as they would've been implicitly
assigned anyways.
While here, throw terminating commas after the last value of tables.
It should use the common parser, but it should not be processed like a
standard file. Rewite check_nextboot to read the file in, check whether it
should continue, then parse as needed.
This allows us to throw the recently introduced check_and_halt callback
swiftly out the window.
config.parse is now purely a parser, rather than a whole proccessor. The
standard process for loading a config file has been split out into
config.processFile.
This clears the way for having nextboot read its own config file and decide
there whether it should parse the rest of the file.
This is step 1 towards revoking config.parse of it I/O privileges. Ideally,
all reading would be done before config.parse and config.parse would just
take text and parse it rather than being charged with the entire process.
Functionally, the latter error wouldn't necessarily hurt anything. io.write
will just error out as it's not passed a valid file handle. Still, we can do
better than that.
The functionality was correct, but our style guidelines tend to request that
we shy away from using boolean operations in place of explicit comparisons
to nil.
config.parse now takes an extra callback that is invoked on the full text of
the config file. This callback dictates where we should actually try to
parse this file or not.
For nextboot, we use this to halt parsing if we see 'nextboot_enable="NO"'.
If we don't, parse it and write 'nextboot_enable="NO" ' to it. The same
caveat as with forth still applies- writing is only supported by UFS.
Write support (even if it only works on UFS) will be needed for nextboot
functionality.
Reviewed by: cem, imp
Differential Revision: https://reviews.freebsd.org/D14478
We don't support float in the boot loaders, so don't include
interfaces for float or double in systems headers. In addition, take
the unusual step of spiking double and float to prevent any more
accidental seepage.
We need to ensure that we defined Numbers as int64_t everywhere we
build for lua. Previously, we were compiling part of the code with
Numbers as int64_t and part as double. Move lua number definition to a
more-central location
