netdev - Re: [PATCH 1/2] net: linkwatch: send change uevent on link changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJ2ouayyCkPzamW69pQ=+fRX4SvEwxwJ3hRCCh7Xb6D-Fafa7w@mail.gmail.com>
Date:   Thu, 6 Dec 2018 21:40:56 +0100
From:   Jouke Witteveen <j.witteveen@...il.com>
To:     davem@...emloft.net
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] net: linkwatch: send change uevent on link changes

On Thu, Dec 6, 2018 at 9:10 PM David Miller <davem@...emloft.net> wrote:
>
> From: Jouke Witteveen <j.witteveen@...il.com>
> Date: Thu, 6 Dec 2018 09:59:20 +0100
>
> > On Thu, Dec 6, 2018 at 1:34 AM David Miller <davem@...emloft.net> wrote:
> >>
> >> From: Jouke Witteveen <j.witteveen@...il.com>
> >> Date: Wed, 5 Dec 2018 23:38:17 +0100
> >>
> >> > Can you elaborate a bit? I may not be aware of the policy you have in
> >> > mind.
> >>
> >> When we have a user facing interface to do something, we don't create
> >> another one unless it is absolutely, positively, unavoidable.
> >
> > Obviously, if I would have known this I would not have gone through
> > the trouble of investigating and proposing this patch. It was an
> > honest attempt at making the kernel better.
> > Where could I have found this policy? I have looked on kernel.org/doc,
> > but couldn't find it.
>
> It is not formally documented but it is a concern we raise every time
> a duplicate piece of user facing functionality is proposed.

Ok, thanks for getting back to me! Now I know.

That said, when looking into udev I became more convinced that the
kernel should send uevents on link state changes anyway. An example of
another kernel interface that has two ways of sending out state
changes is rfkill. It informs userspace of state changes via
/dev/rfkill and via uevents. For the latter it also sets some
informative environment variables, which my patch currently does not
do.

What would be needed to get you (or anyone else) to reconsider this
patch (or a revision)? I can definitely see your point and am willing
to accept your rejection. However, I also think there are substantial
ergonomic benefits to a unified and consistent interface for device
state changes and would like to give it one more shot, if possible.

Thanks for your time,
- Jouke