The name "console" is sort of ambiguous. It could mean:
1) the keyboard and mouse together (also known as "seat")
2) the VT console
3) /dev/console
4) where /dev/console messages should go
In this case we mean 4, so we rename it to kernel_console_tty
for clarity.
In cases where, before the file system is mounted, there is a very long pause,
the progress would continue all the way to 100% assuming a 60 second boot time.
It now stops at 25% to signal that something is wrong and moves to crawl mode
(nudging forward very very slowly).
The inheritance works primarily on objects and functions.
Object example:
A.v1 = 1;
A.v2 = 2;
B.v2 = 7;
B.v3 = 3;
C = A | B;
C is now equal to A with B as a base (C.v1 = 1, C.v2 = 2, C.v3 = 3).
A and B remain unchanged.
Function example:
fib = fun (a) if (a < 2) 1; else fail;
| fun (a) if (fibcache[a]) fibcache[a] ; else fail;
| fun (a) fib (a - 1) + fib (a - 2); ;
Fail means a function is aborted and a more base function is attempted.
This is now also looked up when evaluating vars. Vars are looked for in the
local context, then within this (current object) and finally within the
global context;
We've been using the inst function provided by mkinitrd
to install plymouth and its dependencies into the initrd
root, but mkinitrd may not be installed in a dracut world,
and dracut has its own inst function.
This commit tries getting access to either of them, before
bailing. At some point we may want to bundle our own inst
function or get a new flag added to /usr/bin/install to do
what inst does.
As_bool now returns false for 0.0 and NAN. It uses the fpclassify which should
be a clean way of testing for zero. The as_number function simplifies a switch
to an if.
The progress percentage is now settable. By "settable" this doesn't mean the
value will change to the new value, the set value is only a hint as to where
the progress should be at this point in time. So it it overshot or under-run,
the hint is used to determine how much time is left, and how fast to move the
bar.
When functins are called as an element of an object (e.g. obj.func(par) ), the
object is passed into the function execution as "this" in the local context.
Rather than directly accessing hash tables when accessing variables, use the
abstraction functions. Adds a peek function which does not create a new object
is one has not been defined already.
This removes some of the duplication due to the two methods of creating
functions. Now function definitions like:
fun name (foo) {bar}
are treated as
name = fun (foo) {bar};
No script code needs to change as both are still valid.
One useful way to use plymouth is by installing it into
an auxillary initrd image, that overlays the primary one.
This allows plymouth and its current theme to get updated
indepedently of the kernel and the rest of the initrd
stuff.
plymouth-generate-initrd creates an initrd named:
initrd-plymouth.img
in /boot that is suitable for use a second initrd on
the initrd line in grub.conf.
Previously, we'd try to guess the plugin path based
on the arch of the running process. That's sort of
fragile, so better to just install plugins where
plymouth says it's going to look for them.
Some modules (the label plugin in particular) use
libraries with static data that don't do well with
being unmapped and remapped later.
This commit changes the module loading call so that
plugins aren't unmapped at close time (the close
is effectively ignored). This simplifies things
for now.
At some point we may want to make it decidable on
a per plugin basis.
