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.
Progress bar expansion was previously halted on password entry. Now the
progress can be halted whenever the system wishes. This can be useful when the
system notices there is a big task which is normally not present during normal
boots e.g. fsck.
Previously the splash plugins would deal with password entry, which would mean
that code was repeated and upon splash unload the password entry would be lost.
Now the keyboard strokes are processed with outside the splash, and the plugins
only deal with showing an appropriate user interface. As well as password
entry, the system can ask questions with non hidden text entry and sensing of
keystrokes.
In some instances, ply-buffer did not terminate the data block with a '\0'.
Doing so allows the data to be used as a string. Additionally it now tries
harder to deal with very long additions to the buffer by repeatedly expanding
the capacity and dealing with appends larger than the maximum buffer size.
free() allows NULL so there is no reason ply_image_free
shouldn't. This also papers over a bug in the solar
plugin that we haven't been able to identify yet.
Normally when a user runs plymouth-set-default-plugin
to change which plugin plymouth uses, the change doesn't
take effect until a new kernel is installed and the initrd
is rebuilt.
This new --rebuild-initrd argument forces the currently
running initrd to get rebuilt immediately (bug 18297).
Somehow a user was running into a case where plymouthd
would busy loop taking 100% cpu. gdb revealed that it
was stuck trying to process keyboard input. This is
apparently because we were looping forever when mbrlen()
got a NUL byte.
This stops the progress from reaching 100% in cases such as fsck and timeouts.
It also averages the progress times from the previous one with the current one
to average out occasional slow tasks.
The background image previously was low resolution
and created various artifacts when being upscaled
to the native resolution of the panel. This patch
ditches the background image and instead generates
a similar type of background dynamically, custom
fit to the screen it's being displayed on. As an
added bonus, since we're doing it dynamically, we
can make some of the stars in the background
lightly twinkle.
It creates a feedback loop. We'll need to cut
that first before we can log to boot.log.
What'd I'd like to do is have several log targets
plymouth:log=boot.log or plymouth:log=/dev/ttyS0,
or plymouth:log=/dev/tty0
