On Tue, 07.08.12 16:35, Václav Pavlín (vpav...@redhat.com) wrote: > Hi everyone, > > I started to work on these two bugs (if I solve the first one, the > second one will be almost solved as well): > > https://bugzilla.redhat.com/show_bug.cgi?id=748512 > https://bugzilla.redhat.com/show_bug.cgi?id=790768 > > My idea is to get list of loaded units, then list of unit files and then > get info for units, which are in file list, but not in list of loaded > units. Then I can print info for all units available in the system > (whether they are loaded or not).
I am not sure we should include the units from "list-unit-files" in the output of "list-units", as this would increase the output quite a bit, and would be hardly helpful in many cases, and slow. There are differences between the concepts of loaded unit and unit file on disk. Some units do not exist as unit files, some unit files don't exist as units. Some files exist in many instances, and so on. Yes, it probably make sense to have a way to generate a list of all units and all unit files, and merge it in some way, but I am not sure that should be exposed as "list-units" nor as "list-unit-files". Also, this option is necessarily slow, since (like list-unit-files) goes to disk and parses a lot of files, hence this is nothing we should confront the user with on first sight, but only on explicit request. So, dunno, I am not entirely sure how to expose this best. We probably should get the interface right, and agree how this would be exposed to the user, before we actually think about implementing it. Neither of the three options I currently see (extend "systemctl list-units", extend "systemctl list-unit-files", add a new systemctl verb) are that pretty in my eyes. If we present the user with a list like this we probably should show a tree view of some kind since the unit file getty@.service might get instantiated a couple of times as "getty@tty1.service" and so on, and hence is in a tree-like relationship. Michal, Kay, do you have any suggestions how we should expose this? Another option would be to add a notice about "systemctl list-unit-files" in the footer of "systemctl list-units". That should already be a big imprvoement, since most people probably interrpet the current advice of using "--all" like this. Another option would be to add "systemctl complete" as hidden option for usage only by bash completion, that does the merging. > I would extract code responsible for loading unit_infos from > systemctl.c/list_units to the function (so it will be reusable) and do > the same with the systemctl.c/lis_unit_files. > > I would like to use hashmap to store loaded units, because it will be > faster, than using array, to check it against unit file list. With this > it would be nice to use hashmap directly in functions list_units and > output_units_list, so I don't have to move data from array to hashmap > and back to array. Yes, storing this in a hashmap does make sense. But really, before we get hacking we should think about the UI of this. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
