Currently, systemd-analyze is written in python. This is a complete rewrite of it in C, allowing us to move systemctl dot in it. A new configure switch has been added to disable it since it requires cairo.
Created attachment 73980 [details] [review] move struct unit_info from systemctl to dbus-common
Created attachment 73981 [details] [review] introduce bus_parse_unit_info in dbus-common
Created attachment 73982 [details] [review] use bus_parse_unit_info in systemctl
Created attachment 73983 [details] [review] rewrite systemd-analyze in C
Created attachment 73984 [details] [review] move systemctl dot to systemd-analyze
Created attachment 73985 [details] [review] move systemctl dot to systemd-analyze
Hmm, how does this relate to this work: http://lists.freedesktop.org/archives/systemd-devel/2013-February/008617.html Can we merge both approaches?
(In reply to comment #7) > Hmm, how does this relate to this work: > > http://lists.freedesktop.org/archives/systemd-devel/2013-February/008617.html > > Can we merge both approaches? Ouch! How unfortunate! I'll have to investigate, I certainly do not want either effort to be lost. Give me some time to compare and read the code.
First thoughts: we should really not link against cairo here, so I'm heavily leaning towards Simon's approach.
Created attachment 74291 [details] [review] systemd-analyze: rewrite in C. Merged approach. This patch sits on top of Marc-Antoine's first three patches. It combines my previous version with some ideas from Marc-Antoine's version. I did not yet merge systemctl dot because i have 2 questions about it: - how do we do this without breaking the interface stability promise? just exec systemd-analyze from systemctl and change the docs to refer to systemd-analyze? - "dot" is somehow ambiguous since it just refers to the output format. so while we are changing the interface, maybe we could come up with something more descriptive. "dependency-graph" or just "dep-graph"? other ideas?
(In reply to comment #10) > Created attachment 74291 [details] [review] [review] > systemd-analyze: rewrite in C. Merged approach. > > This patch sits on top of Marc-Antoine's first three patches. > > It combines my previous version with some ideas from Marc-Antoine's version. > > I did not yet merge systemctl dot because i have 2 questions about it: > - how do we do this without breaking the interface stability promise? It's a "debug tool". I see no problem really to move it. It never really belonged into systemctl from today's view. > just exec systemd-analyze from systemctl and change the docs to refer to > systemd-analyze? Change the docs to reflect the new location only. > - "dot" is somehow ambiguous since it just refers to the output format. > so while we are changing the interface, maybe we could come up with > something more descriptive. > "dependency-graph" or just "dep-graph"? > other ideas? Sounds fine. It will also allow us to add an output format option if some fancy new format is better than dot.
Agreed with Kay's comments - should be resolvable easily as well.
Created attachment 74315 [details] [review] move systemctl dot to systemd-analyze depgraph
Please note that this also duplicates Bug # 37809 .
(In reply to comment #14) > Please note that this also duplicates Bug # 37809 . I've closed this one as "wontfix" - basically rejecting the other implementation. I'm not sure what proper bugzilla procedures are but this isn't a duplicate as the other bug specifically asks for a vala implementation instead. This way seems a bit more precise to me.
Hmm, do we really want to rename this from "dot" to "depgraph"? "dot" might not be the same name, but is "depgraph" really that much better? At least in my mind "dot" is closely associated with graph theory, so I think "dot" is actually an OK name? Do you expect more verbs that would output dot files, so you want to keep the avenue open? Opinions?
(In reply to comment #16) > Opinions? I have no problems with 'dot' really...
Merged after a few minor changes - I kept the dot command "dot" in the end. thanks to everyone for putting in the effort!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.