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

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 06, 2014 at 05:14:17PM +0200, Lennart Poettering wrote:
> 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 it's like a hash table, i.e. approx %50 empty on purpose.

At least in case load load-fragment-gperf, we are trading a bit of
space for speed in an important code path, so I'm sure it is worth
it. The errno stuff isn't probably that important, because iiuc we
won't even load this page until it is used, so again, this seems fine.

Zbyszek