[systemd-devel] Optimizing systemd binaries for small deployments
hw at travelping.com
Fri Mar 29 13:04:07 PDT 2013
----- Original Message -----
> On Wed, 27.03.13 11:49, Tino Breddin (tbreddin at tpip.net) wrote:
> > Hi there,
> > We are in the process of creating a very small image for devices with
> > a maximum of 4MB flash. Compared to a SysV variant which clocks in at
> > ~1MB using Systemd we are currently getting images sizes of ~10MB. At
> > first glance the systemd binaries seem quite large. Before diving into
> > lots of optimization I wanted to ask whether anybody has pointers we
> > should follow or even experience using systemd for bare minimum
> > images.
> Well, a few notes:
> There are tons of configure options for optional featutres, make sure
> you enable exactly what you need, and not more. Also, we could make even
> more stuff optional, if it's sufficiently peripheral.
We will go into more details here later, lets say in the next 4-6 week, currently
we have tight schedule for a project which also have the 4MB flash limit.. so not
much time to spend right now...
> Also note that we ship a couple of databases with generic device info,
> such as hwdb, keymaps and the rules set. They tend to be quite small,
> but if dunno, you could minimize this too. Probably not worth it though.
The DBs we already have on our radar for optimisation....
> We currently compile a lot of code into each binary,
> and rely on gc-sections to clean this up for us. If minimal disk
> footprint is key, then you could split this shared code into a private
> .so or so.
May thats an option to consider ad we would like to check this and discuss
the options here.
> Then, there's a ton of stuff we more or less replaced with systemd, so
> you can drop cron, pm-utils, acpid, at, rsyslog, inetd, ckit,
> initscripts, watched, cgrulesd, and more, because you don't really need
> it anymore...
You are exactly right if you have classic desktop (or server) distributions
like Fedora, Redhat, arch etc. as focus. If you come from the embedded direction
i.e. OpenWRT, you don't have all this stuff anyway, so not much space gain here.
I agree with the savings on init scripts, but here again, a typical embedded Linux
system has about 20-30 Services and not hundreds shipping the own config files.
One could and will argue why Systemd at all in embedded Systems, but we think there
ist still a lot to gain by using systemd, but lets keep they eyes open when developing
systemd further. I remember the blame commands written in python and a huge bunch
of dependencies attached, luckily someone was coming along to rewrite the thing.
> Lennart Poettering - Red Hat, Inc.
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
email: hw at travelping.com
More information about the systemd-devel