[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 06, 2014 at 02:57:17PM +0200, Lennart Poettering wrote:
> > systemd does a lot. And an 1,3 MiB binary is a hug binary size for something 
> > that started out as managing services and sessions via control
> > cgroups.
> 
> Well, it does a lot more these days. 
> 
> The Linux kernel also started out pretty small too. Nowadays it does a
> lot more, which makes it so unversially applicable. I figure systemd
> goes a similar path. (Though hopefully will never grow as massive,
> complex and monolithic as the kernel...)
This is an interesting question, where this 1.3 MB comes from.

objdump -t ./systemd|sed -r -n 's/([0-9a-z]+).*(\.text|\.data\.[a-z.]*|\.rodata\.[a-z.]*)[ \t]*([0-9a-z]+)[ \t]*(\.hidden[ \t]+|)(.*)/\3 \5 -- \2/p'|sort|tail

0000000000000a13 service_deserialize_item -- .text
0000000000000a6e cgroup_context_apply -- .text
0000000000000ae2 socket_apply_socket_options -- .text
0000000000000b00 rtnl_types -- .data.rel.ro.local
0000000000000b32 exec_context_dump -- .text
0000000000000d50 bus_exec_vtable -- .data.rel.ro
0000000000000d62 transaction_add_job_and_dependencies -- .text
0000000000000e40 bus_unit_vtable -- .data.rel.ro
00000000000011d7 bus_cgroup_set_property -- .text
0000000000001410 bus_manager_vtable -- .data.rel.ro
0000000000001453 exec_child -- .text
0000000000001470 wordlist.7848 -- .data.rel.ro.local
0000000000002b90 main -- .text
000000000000e1c0 wordlist.14097 -- .data.rel.ro

wordlist.14097 is a generated table for all configuration options in
load-fragment-gperf.c.

wordlist.7848 is for errno_from_name (5k for this is a bit of a
stretch though).

There's pretty complex code (main is 11k), combined with a large
number of configuration and reporting code (the wordlists, vtables,
exec_context_dump).

This shows that splitting the binary into two would not be really
effective: this code would essentially have to be duplicated, once for
communication between PID 1 and the helper, and second time for
communication between the helpers and the rest, i.e. the existing code.

--

I think this hasn't been mentioned in this thread, but PID1 is
shrinking at least a bit, because a bunch of things which used to be
implemented in PID1 have been outsourced to generators.
./systemd-sysv-generator, ./systemd-fstab-generator are relatively
recent and significant.

Zbyszek