[systemd-devel] [PATCH] RD_TIMESTAMP: support the value being set from /proc/uptime

[Tom Gundersen]

On Fri, Sep 2, 2011 at 4:20 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Thu, 25.08.11 22:59, Tom Gundersen (teg at 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