[systemd-devel] [PATCH] rfkill: Add systemd integration

[Lennart Poettering]

On Mo, 10.12.18 13:53, Karel Zak (kzak at redhat.com) wrote:
65;5402;1c
> On Tue, Nov 27, 2018 at 07:16:04PM +0100, Stanislav Brabec wrote:
> > Sami Kerola wrote:
> > That said,
> > > getting a clarification from Jochen would nice because otherwise we are
> > > simply guessing.
> >
> > Jochen Keil already left SUSE and I have no contact e-mail to him.
> >
> > But I got complain that it is missing after migration of rfkill to util-linux:
> > https://bugzilla.opensuse.org/show_bug.cgi?id=1092820
>
>  It seems the best would be to ask upstream systemd guys. Maybe it's
>  really Suse specific and maybe it's something we can support for more
>  distros. I don't know.
>
>  All thread:
>  https://lore.kernel.org/util-linux/0ce3309a-009a-7c00-3a2c-e4917b894f8c@suse.cz/T/#m221ad50b88792236c10c507f9163b57761c254a7

Hmm, what's the usecase for this?

I mean, "systemctl start rfkill-block at xyz.service" isn't that much
nicer to type than "rfkill block xyz", no? In fact, quite the opposite
I'd say...

Or this is about enable/disabling rfkill at subsequent boot, using
"systemctl enable rfkill-block at xyz.service"? This kinda conflicts with
the save/restore logic systemd-rfkill at .service (as shipped with
systemd) implements already. It might make sense to extend that tool
slightly, for example by defining a udev property or so to check which
can override the saved data statically. Or definining a kernel cmdline
option to override the rfkill save/restore logic globally. But I am
pretty sure that one should be careful with having two different
packages run at boot to set the initial rfkill setting, because they
will fight about it.

Lennart

--
Lennart Poettering, Red Hat