This will be useful for debug purposes.
It's implemented by adding the concept of
"filters" to the logger code. Each time a message
is logged it is passed through all registered
filter handlers and then the output of the filters
are what is actually logged.
In this case, we pass the messages through verbatim,
but also redirect them to a debug buffer.
We only do this redirection when plymouth:debug is
used.
We used to run and remove timeouts in a loop. This
breaks the case where the dispatched timeout handler
removes the timeout itself.
We fix it by making timeout handling a two pass thing.
First we find which handlers need to be dispatched,
and move them to their own list. Then we run through
the new list and dispatch the handlers.
init does two rounds of killing at shutdown:
a round of SIGTERMs and a round of SIGKILLs.
We want to stay alive until the SIGKILL round
so we ignore the SIGTERM signal.
Plymouth client ask-for-password and ask-question commands have their option
"--pause-progress" changed to "--dont-pause-progress". By default progress is
paused and "--dont-pause-progress" has to be supplied to not pause.
We used "rhgb" because that's what Fedora users were used to
instinctively removing when graphical boot messes up. This
isn't a very intuitive (or very upstream-y) name though.
Now we check for "rhgb" or "splash"
If we don't then someone during boot up may change
out from raw when we aren't looking.
Maybe we should use TIOCSLCKTRMIOS to prevent that
from happening? Or maybe we should bypass the tty
for input entirely and use evdev?
Previously ply-entry was crashing with an assertion "entry->loop == NULL"
whenever the entry was updated. The change is basicly a copy of the working
version from spinfinity.
This will play a sequence of images from beginning to end at
a fixed frame rate. It differs from the throbber in that it starts
at the 0th image and does not repeat.
With integer options there's no obvious value to mean "unset" like there is for
string types (and to a lesser extent boolean types), so this commit
adds a mechanism.
Hashtable uses the bitarray to mark the used/dead places in the hash data array.
The hashtable functions follow the general gist of the glib ones. To create a
hashtable you supply the hashing and comparison functions. Examples of direct
and string based indexing are supplied. Hashtable is a single word because there
is no hash_somethingelse but the name may change soon. Notice the compare
function returns a signed int difference rather than an equal bool. This is
because it may be an idea to later migrate the collision system to a tree
sub-structure (currently it is a linear array search with an incrementing step
size).
The new limit is 2^32. This only affects the replies to the client. Data sent
along with requests (e.g. password prompt) remain limited to <256 characters.
Two new functions have been added to the ply-utils (ply_read_uint32 and
ply_write_uint32) which receive/transmit 32bit numbers on FD streams.
AFAICT in function ply_boot_client_process_incoming_replies the answer was not
NUL terminated, which may have caused some of the password error bugs.
The "Rework input methods" commit broke the pausing of the progress bar during
password entry. This commit reimplements that functionality but this time the
pausing is optional, applied with a --pause-progress parameter. The client
program sends the (un)pause commands before/after the password requests.
The default is currently to not pause but that may change quite soon.
This also fixes a couple minor bugs and formatting from "Rework input methods".
Also changed "progress-pause" to "pause-progress" to make it more human
intuitive.
When asking for a password or a question, if the user presses Ctrl+C or Ctrl+D
the backend will reply a NULL. This is interprited as a "Stop asking me". The
client will not repeat the request (even if number of retries hasn't been
reached) and quit with an error exit_status.
