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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel