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  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]
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

Powered by blists - more mailing lists