[systemd-devel] [PATCH][RFC][V2] systemd-analyze: rewrite in C. (Was: systemd-analyze-197 broken)
Kok, Auke-jan H
auke-jan.h.kok at intel.com
Tue Jan 22 22:17:27 PST 2013
On Tue, Jan 22, 2013 at 7:46 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 22.01.13 16:15, David Strauss (david at davidstrauss.net) wrote:
>> I was writing up a bunch of arguments in favor of DOT (now deleted
>> after reviewing the existing "analyze" output and how DOT would not be
>> good for achieving it). But, I'd really prefer moving the output to
>> something more semantic like callgrind [1] or HAR [2]. DOT is
>> certainly more semantic than SVG, but it's nowhere near callgrind and
>> HAR.
>
> While we generally try to avoid supporting too many different formats
> and protocols in systemd, and only support those we really know we can
> support for good and make work well, and where we know they have a
> strong future I think "systemd-analyze" being primarily an analysis tool
> and not being part of the usual system management code paths would
> benefit from different output formats, even if those might be slightly
> more exotic. I have no experience with HAR and it's not obvious how this
> applies to systemd-analyze, but if it has nice tools that can process it
> I am all for it.
>
> BTW, "systemctl dot" can generate dot files, but it's not as useful as
> one might hope, since the networks are just too massive. (Thinking about
> it, if we now have systemd-analyze in C we really should move
> systemctl's dot command there too.)
We should really do that - a lot of infrastructure to do this already
is available in the C rewrite by Simon, and it's just a matter of
doing a clean import of the `systemctl dot` logic from there on, but I
have to check that we have all the data available through the DBus
interface, it might ultimately be slower than `systemctl dot`, but I
don't think that should stop us.
I'm pushing for cleaning up Simon's patch and including it in the tree
- it will directly replace the python code since the output and
interface is consistent with the old output.
Auke
More information about the systemd-devel
mailing list