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

[Kay Sievers]

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".

> i tought maybe we can redo this "interface" at the same time, to make
> it integrate more with  the other systemctl commandos.
>
> here is what i currently think could be a good way to add udev control
> in systemctl:
>
> systemdctl
>         daemon-reload: also reload udev rules
>
>         udev
>                 trigger [type] [action]
>                 set <key>=<value>
>                 stop-exec
>                 start-exec
>                 test [action] <syspath>
>                 builtin <command> <syspath>
>                 settle [filename]
>                 monitor [kernel/udev/both]
>                 db export/cleanup
>                 query <name/symlink/path/property/all> <path=/name=>
>                 attribute-walk <path=/name=>
>                 device-id-of-file <file>

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.

Kay