| 1 |
On Tue, Jan 20, 2015 at 2:58 PM, Marc Stürmer <mail@×××××××××××××.de> wrote: |
| 2 |
> Zitat von Tom H <tomh0665@×××××.com>: |
| 3 |
> |
| 4 |
>> Lennart claims that the embedded world loves systemd. I suspect that, |
| 5 |
>> as in other corners of the Linux world, there are lovers and haters of |
| 6 |
>> systemd. |
| 7 |
> |
| 8 |
> |
| 9 |
> Embedded systems also quite often means low on resources, CPU power, memory, |
| 10 |
> space. |
| 11 |
> |
| 12 |
> If you are using hard space constrained systems, the sheer size of systemd |
| 13 |
> in the file system can be a valid reason not to use it at all. |
| 14 |
> |
| 15 |
> So it does depend on the type of embedded system you are looking at. |
| 16 |
> |
| 17 |
|
| 18 |
True. I've actually started comparing the direction systemd is moving |
| 19 |
in with busybox. The latter is of course already popular in embedded |
| 20 |
environments for the reasons you state. |
| 21 |
|
| 22 |
If you really want something super-minimal busybox is probably more of |
| 23 |
what you're looking for. On the other hand, if you want something |
| 24 |
more functional but still generally integrated then systemd might be |
| 25 |
the right solution. |
| 26 |
|
| 27 |
RAM use for systemd (plus its deps) seems to be on the order of maybe |
| 28 |
2MB or so depending on what features you have resident (journal/etc). |
| 29 |
Most systemd utilities do not run continuously. Some of the shared |
| 30 |
memory use for systemd deps may be consumed already depending on what |
| 31 |
else is running on the system. Many systemd components would not |
| 32 |
necessarily need to be installed on-disk for an embedded system. For |
| 33 |
example, command-line utilities used by administrators to control |
| 34 |
their system might not need to be installed for systemd to still |
| 35 |
function (you don't need to manually change the runlevel of an |
| 36 |
embedded device, start/stop modules, etc - and all these tasks can be |
| 37 |
controlled over dbus without using the binaries on disk so your |
| 38 |
embedded application can still manage things). I'm not sure how |
| 39 |
systemd works with glibc alternatives, etc. |
| 40 |
|
| 41 |
If you can dispense with a shell entirely by moving to systemd then |
| 42 |
there could actually be some savings on that end, and performance will |
| 43 |
certainly be better. |
| 44 |
|
| 45 |
This page seems to be a fairly neutral/factual exploration of this issue: |
| 46 |
https://people.debian.org/~stapelberg/docs/systemd-dependencies.html |
| 47 |
|
| 48 |
This isn't really intended as a "systemd is the right tool for every |
| 49 |
embedded solution" or "systemd is a horrible tool for embedded" |
| 50 |
argument. It just is a tool and in the embedded world you should |
| 51 |
weigh its pros/cons as with anything else. Most likely an embedded |
| 52 |
environment is going to be highly-tailored in any case, so you'll be |
| 53 |
wanting to seriously consider your options for every component. If |
| 54 |
your embedded device is more like a phone with (relatively larger) |
| 55 |
gobs of RAM then systemd may be advantageous simply for its ubiquity. |
| 56 |
|
| 57 |
-- |
| 58 |
Rich |
Archives