On Fri, Sep 2, 2011 at 4:20 AM, Lennart Poettering <lenn...@poettering.net> wrote: > On Thu, 25.08.11 22:59, Tom Gundersen (t...@jklm.no) wrote: > >> This is useful to be able to use systemd-analyze with initrd's that don't >> have systemd support. In particular, Arch's initrd exports RD_TIMESTAMP >> on this format. I also believe dracut falls back to this when >> systemd-timestamp >> is not present. > > When I wrote this I was thinking about allowing the /proc/uptime format > for this, but decided against it for a number of reasons. Instead I > preppaed systemd-timestamp for inclusion in initrds. I am not a fan of > allowing too many variables in the game where they bring no clear > benefit. Hence my question: why? Why can't your initrd simply include > systemd-timestamp in the image, the same way we do it on dracut? (the > binary has no deps, so there's nothing stopping you really).
Since systemd is not our only (nor even the default) init system, and it probably won't be for some time, we'd rather not add systemd-specific stuff to our initrd (especially when the benefit is so small). I am all in favor of sharing the protocols between all initrd/init implementations (we also have support for /run/initramfs in both our initrd and initscripts). I also think it makes sense that you get the best result (in this case highest precision) if you use the "blessed" combination of packages (systemd+dracut). However, it would be nice if there could be a fallback that would also work if you choose to swap out some of the components. Since dracut (afaik) already falls back to /proc/uptime, and it is the simplest thing to implement from a shell, in case you don't have the systemd binary available, I thought it made a lot of sense to use as the common fallback. Thanks for considering it, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
