On Sat, Jun 08, 2013 at 05:39:48PM +0200, Michael Stapelberg wrote: > Hi Zbigniew, > > Thanks for your answer. > > Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> writes: > > "The binaries systemctl (299 KiB), journalctl (187 KiB) and loginctl > > (91 KiB) are the main binary to use for respective part of system" > > → it's a bit unclear what "to use for" means in this context. > Clarified. > > > "pixel-perfect" → not true for a long time, since now we do coloring > > and such, maybe "character-perfect" would be more adequate > Fixed. > > > "journal log" → journal > Fixed. > > > "there is no cyclic dependency" → actually there's a *compile time* > > cyclic dependency, so it might be good to add an adjective that makes > > it clear that you mean startup order dependency > Fixed. > > > OK, you start talking about systemd, and than about libudev, and > > serial ports, and it all becomes really muddy. Maybe it would be > > better to first get systemd-udevd out of the way, especially that > > udevd is used by everybody, so it is always loaded anyway, so the cost > > of libudev.so.1 in PID 1 is nearly nil. > udevd does not use libudev.so AFAICT. It does not show up in ldd > /lib/systemd/systemd-udevd Right. But other stuff in /lib/udev/ uses it, e.g. accelerometer, cdrom_id, udisks stuff.
> > "To be honest, I don’t quite understand why this code is not inlined > > into systemd. " → why should it be? It is rather worth explaining why > > there's so much stuff in systemd. There's a reason why other code *is* > > inlined into systemd, when it *could* be provided as a shared library. > > The stuff that is part of static libsystemd-shared during compilation > > is inlined and not shared between all the systemd components as a > > shared library because it would have to be installed in /usr/lib and > > other people could link against it. But we don't want to provide any > > promises regarding the stability of the internal library API, so we > > take the (small) cost of static linking over the hassles that come > > with having a private library in a public place. There's no such > > consideration for libsystemd-daemon, because it has a public API that > > is stable. > Fixed. > > > "helper utilities" → why are there crosses and check marks, what's the > > difference? > ✘ means no, ✔ means yes. In the particular case it means whether the > specific binary depends on e.g. udev or not. I thought that’s obvious, > but I’ve clarified it. > > > "systemd-shutdown PID 1 will be replaced with this binary" → when? > > Maybe mention that systemd-shutdown is statically linked (I know it > > can be inferred from the text, but being explicit might be better). > Clarified. > > > "Debugging, interactive tools, shell helpers ... systemd-readahead": > > I would say that systemd-readahead doesn't really fall into any > > of those categories. > Indeed. There’s no better category, though, so I’ll just leave it as-is. > > > "systemd-nspawn ... for debugging" → not really, since it has gained > > the ability to socket activate containers, people use it also for > > production (e.g. compilation chroots, web server environenments, etc). > Added. > > > "systemd-detect-virt ... Depending on your environment, you might not > > want to start certain services — for example udev does not make sense > > in an lxc container" → this is a bit misleading, because services > > would be started or not using systemd's built-in ConditionVirtualization, > > and this binary is for other uses. > For what uses specifically? Don't know off the top of my head, but udevd was just a bad example. systemd-detect-virt is for installation scripts and other stuff which is not tied to systemd directly. > > "so that the only thing journald does is passing information to syslog" > > → it also stores stuff temporarily in tmpfs. > Clarified. > > > What I'm missing from all this, is the answer to the question set > > forth in the title: what is the *total* footprint of running a normal > > systemd installation (I'd be happy to see some good statistics and > > analysis!). PID 1 is probably the heaviest, but journald also > > contributes, and it would be nice to see the whole picture. > I’m working on additional measurements which outline the memory > requirements for an entire sysvinit boot and systemd boot. I’ll update > you once that is done. Great, I hope that this will help in the discussion. Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
