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

[Lennart Poettering]

On Mon, 06.10.14 16:34, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> 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).

I wonder if any of these tables might have holes in them? i.e. some
enums skip a few numbers in the middle, and are thus not really
appropriate for the usual DEFINE_STRING_TABLE() stuff we do?

> 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.

And I'd be willing to split out more, but I am not sure currently what
could be a good candidate.

Lennart

-- 
Lennart Poettering, Red Hat