[systemd-devel] [RFC] adding udev options to systemctl

[Peeters Simon]

2012/8/2 Kay Sievers <kay at vrfy.org>:
> On Thu, Aug 2, 2012 at 10:04 PM, Peeters Simon <peeters.simon at gmail.com> wrote:
>
>> Since systemd and udev are one project now it might be an idea to be
>> able to control both daemons with one tool (systemctl)
>
> We also have journalctl, loginctl, ...
>
> systemctl is about managing services, and udev is very tightly
> integrated, but it's still more a service itself than at the level of
> controlling services.
>
>> also, since i don't like the way the arguments to udevadm work (very
>> unclear about what is a commando and what an option),
>
> The first word is the 'verb', everything else are options to that
> verb. It's not always obvious, but I also think it's not "very
> unclear".

to me it seems to go wrong here, becouse f.ex udevadm info needs an
argument but --help does not help in knowing what arguments you need,
... (just having a verb that needs another "action" which is a '--'
option is not that clear to me, especially if the --help does not tel
you about it)

> Most of them are not useful today, like the daemon operations: set,
> stop-exec, start-exec. And they should really make clear that they
> operate at the running daemon only and nowhere else. Calling things
> with generic words like 'set', which in fact does very specific and
> exotic things, makes not too much sense, I guess.
>
> device-id-of-file is useless today.
>
> builtin is really just a test, and nothing else, and that should also
> be made very clear with the command. It's in no way a general-purpose
> tool to call from something else than a human.
>
> query and db really belong together.
>
> ...
>
>> and maybe we can add some way to know the difference between a device
>> name and a sys-path ( maybe by forcing the later to begin with /sys )
>> and drop the 'path=' and 'name=' in query and attribute-walk
>
> That works already in recent versions.
>
>> of course for compatibility the udevadm command has to stay around for
>> a while, but maybe we can fold it into systemctl with a symlink (like
>> we doe for poweroff, reboot,...)
>
> I don't think we are in the "for a while" department here. I don't
> think we could remove that anytime soon.
>
>> any sugestions/comments are welcome, i am willing to code this if it is wanted.
>
> I'm not really convinced that this really makes things better than
> they are now. If we would do anything like that, we would probably
> throw away 2/3rd of the udevadm stuff and just get a few "systemctl
> device" options. Mapping 1:1, the same stuff udev already pretty
> sufficiently does, to systemctl does not really seem to justify the
> duplication and effort.

i see your point and completely agree on the "throw away 2/3rd of the
udevadm stuff" part, i just did not know which parts were
deprecated/useless. (for what i care i only need trigger and settle)

thanks