On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering
<mzerqung@xxxxxxxxxxx> wrote:
>> "plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?
>
> Because we need to constantly send updates to it. It's a trivial socket
> operation. It's a trivial thing and spawning a separate process to send
> those updates each and every single time is a major waste of resources
> and basically doubles the processes we have to spawn at boot.
The long-term question here is "what happens when Plymouth is replaced
by something different, first in one specialist distribution, later by
one major distribution (perhaps Fedora), and only much later by most
distributions?". Will systemd only support the new thing, forcing the
"slower" distributions to backport patches? Will systemd support both
systems, and over time become burdened with compatibility code?
Something else?
Historically, each distribution had its own system integration scripts
that supported only the tools the distribution cared about, so there
never was a single project fighting with the matrix of N distributions
x M implementations of major features.
>> What is /lib/systemd/systemd-fsck then?
>
> A wrapper, which handles the exit code and reacts properly to it.
>> (Also, most of them don't emit useful info on --help...)
>
> They aren't user binaries. They are in /lib/systemd, not /usr/bin...
But they do implement user-visible functionality, and have
user-visible /proc/cmdline options. Yes, old initscripts didn't
document the behavior either, but the sysadmin (who, for better or
worse, pretty much has to be able to read shell code) could find them
and could understand and debug the boot process by reading /etc/rc.*.
I think that asking the sysadmin to read the C code of systemd to
understand the boot process and how it can be configured is rather
excessive.
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
