On Fri, 02.09.11 09:17, Tom Gundersen (t...@jklm.no) wrote: > > 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
Well, the thing is that RD_TIMESTAMP is an optional feature anyway, and not setting it has no ill effects on things at all. So I am not sure what we'd win by supporting something half-way that is optional anyway... What I'd like to avoid here is have people ship this as default in a big scale, where they really should get the proper timestamps and nothing else. If it really bothers people so much that this tool is built from the systemd tree I'd suggest they add a feature to /bin/date to format CLOCK_REALTIME and CLOCK_MONOTONIC as integer. I am sure the maintainers of coreutils would accept such a patch (it appears CLOCK_REALTIME is already supported to some degree anyway with +%s, so a tiny patch for CLOCK_MONOTONIC shouldn't be that hard.). Whether you patch systemd like this or coreutils shouldn't really matter, except that with coretuils you'd get a correct solution and with /proc/uptime support in systemd you don't. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
