<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/stand/lua/cli.lua, branch releng/12.2</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>MFC lualoader read-conf support: r360420-r360423, r360425, r360427, r360486,</title>
<updated>2020-05-03T03:53:38+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2020-05-03T03:53:38+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=22d90f6746aa6c320949069ebc5ea1ca5aff6bb9'/>
<id>22d90f6746aa6c320949069ebc5ea1ca5aff6bb9</id>
<content type='text'>
\r360505-r360506

r360420:
lualoader config: don't call loader.getenv() as much

We don't actually need to fetch loader_conf_files as much as we do; we've
already fetched it once at the beginning, we only really need to fetch it
again after each file we've processed. If it changes, then we can stash that
off into our local prefiles.

While here, drop a note about the recursion so that I stop trying to
change it. It may very well make redundant some of the work we're doing, but
that's OK.

r360421:
lualoader: config: start exporting readConfFiles

In the process, change it slightly: readConfFiles will take a string like
loader_conf_files in addition to the loaded_files table that it normally
takes. This is to facilitate the addition of a read-conf CLI command, which
will just pass in the single file to read and an empty table.

r360422:
lualoader: cli: add read-conf

This is a straightforward match to the command used by many in forthloader;
it uses the newly-exported config.readConfFiles() to make sure that any
loader_conf_files gets done as appropriate.

r360423:
lualoader: cli: clobber loader_conf_files before proceeding

This makes sure that config.readConfFiles doesn't see a stale
loader_conf_files from before, in case the newly loaded file doesn't set it.

r360425:
config.lua(8): "may should" is not proper grammar

r360427:
config.lua(8): catch up to recently added hooks

While we're here, let's stylize these as functions instead of just raw text.
A future change may allow arbitrary data arguments to be passed some of
these, and the distinction is useful.

r360486:
loader.conf(5): document that loader_conf_files may be clobbered

A future change in lualoader may take some liberties with the
loader_conf_files in the name of efficiency; namely, it may start omitting
it from the loader environment entirely so that it doesn't need to worry
about maintaining any specific value.

This variable has historically been incredibly volatile anyways, as it may
get set to completely different values in any given configuration file to
trigger a load of more files.

Document now that we may not maintain it in the future, but perhaps we'll
reserve the right to change our minds and eventually formally export all of
the loader configuration files that were read using this variable.

r360505:
lualoader: config: add a table for restricted environment vars

This new table should be used for transient values that don't need to end up
in the loader environment. Generally, these will be things that are internal
details that really aren't needed or interesting outside of the config
module (e.g. if we changed how ${module}_* directives work, they might use
this instead).

To start, populate it with loader_conf_files. Any specific value of
loader_conf_files isn't all that interesting; if we're going to export it,
we should really instead export a loader_conf_files that indicates all of
the configuration files we processed. This will be used to reduce
bookkeeping overhead in a future commit that cleans up readConfFiles.

r360506:
lualoader: config: improve readConfFiles, rename to readConf

The previous interface was pretty bad, and required the caller to get some
implementation details correct that it really shouldn't need to (e.g.
loader_conf_files handling) and pass in an empty table for it to use.

The new and much improved interface, readConf, is much less of a hack;
hiding these implementation details and just doing the right thing.
config.lua will now use it to process /boot/defaults/loader.conf and the
subsequent loader_conf_files from there, and read-conf will also use it.

This improvement submitted by Olivier (cited below), loader_conf_files
handling from the original patch was changed to just clobber it before
processing and not bother restoring it after the fact following r360505
where it's now guaranteed to evade the loader environment.

PR:		244640
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
\r360505-r360506

r360420:
lualoader config: don't call loader.getenv() as much

We don't actually need to fetch loader_conf_files as much as we do; we've
already fetched it once at the beginning, we only really need to fetch it
again after each file we've processed. If it changes, then we can stash that
off into our local prefiles.

While here, drop a note about the recursion so that I stop trying to
change it. It may very well make redundant some of the work we're doing, but
that's OK.

r360421:
lualoader: config: start exporting readConfFiles

In the process, change it slightly: readConfFiles will take a string like
loader_conf_files in addition to the loaded_files table that it normally
takes. This is to facilitate the addition of a read-conf CLI command, which
will just pass in the single file to read and an empty table.

r360422:
lualoader: cli: add read-conf

This is a straightforward match to the command used by many in forthloader;
it uses the newly-exported config.readConfFiles() to make sure that any
loader_conf_files gets done as appropriate.

r360423:
lualoader: cli: clobber loader_conf_files before proceeding

This makes sure that config.readConfFiles doesn't see a stale
loader_conf_files from before, in case the newly loaded file doesn't set it.

r360425:
config.lua(8): "may should" is not proper grammar

r360427:
config.lua(8): catch up to recently added hooks

While we're here, let's stylize these as functions instead of just raw text.
A future change may allow arbitrary data arguments to be passed some of
these, and the distinction is useful.

r360486:
loader.conf(5): document that loader_conf_files may be clobbered

A future change in lualoader may take some liberties with the
loader_conf_files in the name of efficiency; namely, it may start omitting
it from the loader environment entirely so that it doesn't need to worry
about maintaining any specific value.

This variable has historically been incredibly volatile anyways, as it may
get set to completely different values in any given configuration file to
trigger a load of more files.

Document now that we may not maintain it in the future, but perhaps we'll
reserve the right to change our minds and eventually formally export all of
the loader configuration files that were read using this variable.

r360505:
lualoader: config: add a table for restricted environment vars

This new table should be used for transient values that don't need to end up
in the loader environment. Generally, these will be things that are internal
details that really aren't needed or interesting outside of the config
module (e.g. if we changed how ${module}_* directives work, they might use
this instead).

To start, populate it with loader_conf_files. Any specific value of
loader_conf_files isn't all that interesting; if we're going to export it,
we should really instead export a loader_conf_files that indicates all of
the configuration files we processed. This will be used to reduce
bookkeeping overhead in a future commit that cleans up readConfFiles.

r360506:
lualoader: config: improve readConfFiles, rename to readConf

The previous interface was pretty bad, and required the caller to get some
implementation details correct that it really shouldn't need to (e.g.
loader_conf_files handling) and pass in an empty table for it to use.

The new and much improved interface, readConf, is much less of a hack;
hiding these implementation details and just doing the right thing.
config.lua will now use it to process /boot/defaults/loader.conf and the
subsequent loader_conf_files from there, and read-conf will also use it.

This improvement submitted by Olivier (cited below), loader_conf_files
handling from the original patch was changed to just clobber it before
processing and not bother restoring it after the fact following r360505
where it's now guaranteed to evade the loader environment.

PR:		244640
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r352314: lualoader: Add reload-conf loader command</title>
<updated>2019-10-06T04:01:15+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2019-10-06T04:01:15+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=ad6da00b414bd6a4755a49fb54a7b83dc4b8f905'/>
<id>ad6da00b414bd6a4755a49fb54a7b83dc4b8f905</id>
<content type='text'>
This command will trigger a reload of the configuration from disk. This is
useful if you've changed currdev from recovery media to local disk as much
as I have over the past ~2 hours and are tired of the extra keystrokes.

This is really just a glorified shortcut, but reload-conf is likely easier
to remember for other people and does save some keystrokes when reloading
the configuration. It is also resilient to the underlying config method
changing interface, but this is unlikely to happen.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This command will trigger a reload of the configuration from disk. This is
useful if you've changed currdev from recovery media to local disk as much
as I have over the past ~2 hours and are tired of the extra keystrokes.

This is really just a glorified shortcut, but reload-conf is likely easier
to remember for other people and does save some keystrokes when reloading
the configuration. It is also resilient to the underlying config method
changing interface, but this is unlikely to happen.
</pre>
</div>
</content>
</entry>
<entry>
<title>MFC r340040, r340152: lualoader boot-conf and chainload</title>
<updated>2018-11-08T03:25:18+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2018-11-08T03:25:18+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4532ac986d1c9cfccba7efdc2e5be0f9e28062c8'/>
<id>4532ac986d1c9cfccba7efdc2e5be0f9e28062c8</id>
<content type='text'>
r340040:
lualoader: Implement boot-conf

r340152:
lualoader: Add chainload menu entry

Approved by:	re (rgrimes)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
r340040:
lualoader: Implement boot-conf

r340152:
lualoader: Add chainload menu entry

Approved by:	re (rgrimes)
</pre>
</div>
</content>
</entry>
<entry>
<title>Remove "All Rights Reserved" on files that I hold sole copyright on</title>
<updated>2018-05-09T16:44:19+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2018-05-09T16:44:19+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4b3c64f7227d603d085bfb494d63e4b4e8804900'/>
<id>4b3c64f7227d603d085bfb494d63e4b4e8804900</id>
<content type='text'>
See r333391 for more detail; in summary: it holds no weight and may be
removed.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
See r333391 for more detail; in summary: it holds no weight and may be
removed.
</pre>
</div>
</content>
</entry>
<entry>
<title>lualoader: Return status in cli_execute_unparsed properly</title>
<updated>2018-03-07T22:05:23+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2018-03-07T22:05:23+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=f6e00525db29a45720221da61dfca46dcd944eb6'/>
<id>f6e00525db29a45720221da61dfca46dcd944eb6</id>
<content type='text'>
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")
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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")
</pre>
</div>
</content>
</entry>
<entry>
<title>lualoader: Fix name, cli.execute_unparsed -&gt; cli_execute_unparsed</title>
<updated>2018-03-07T18:28:41+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2018-03-07T18:28:41+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=ca3b8c9fc4ad3bcbf622d3f90e43a19dc1844fc7'/>
<id>ca3b8c9fc4ad3bcbf622d3f90e43a19dc1844fc7</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>lualoader: Expose loader.parse and add cli_execute_unparsed</title>
<updated>2018-03-07T18:25:27+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2018-03-07T18:25:27+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=697f127dd6427aa5161ad92826e2a7d6796843a0'/>
<id>697f127dd6427aa5161ad92826e2a7d6796843a0</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>lualoader: Return meaningful value in cli_execute</title>
<updated>2018-03-04T03:21:12+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2018-03-04T03:21:12+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=c6d9f133b34b37813abc902f084d068c81f48544'/>
<id>c6d9f133b34b37813abc902f084d068c81f48544</id>
<content type='text'>
loader.command(...) will return whatever the executed function returns, so
follow suit and return whatever loader.command() returned or whatever the
Lua function returns.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
loader.command(...) will return whatever the executed function returns, so
follow suit and return whatever loader.command() returned or whatever the
Lua function returns.
</pre>
</div>
</content>
</entry>
<entry>
<title>lualoader: Explain deviation from naming guidelines</title>
<updated>2018-02-25T05:14:06+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2018-02-25T05:14:06+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=22ae8ae1f47f1aefa5e15213eedf159a5e697560'/>
<id>22ae8ae1f47f1aefa5e15213eedf159a5e697560</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>lualoader: Clean up naming conventions a little bit</title>
<updated>2018-02-24T20:21:21+00:00</updated>
<author>
<name>Kyle Evans</name>
<email>kevans@FreeBSD.org</email>
</author>
<published>2018-02-24T20:21:21+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=322a2dddba49d04539cc130cd2264a00db45c20d'/>
<id>322a2dddba49d04539cc130cd2264a00db45c20d</id>
<content type='text'>
We mostly use camel case for function names, but some local functions got
mixed in using internal underscores. Doubles down on camel case.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We mostly use camel case for function names, but some local functions got
mixed in using internal underscores. Doubles down on camel case.
</pre>
</div>
</content>
</entry>
</feed>
