On Thu, Dec 6, 2018 at 9:10 PM David Miller <da...@davemloft.net> wrote: > > From: Jouke Witteveen <j.wittev...@gmail.com> > Date: Thu, 6 Dec 2018 09:59:20 +0100 > > > On Thu, Dec 6, 2018 at 1:34 AM David Miller <da...@davemloft.net> wrote: > >> > >> From: Jouke Witteveen <j.wittev...@gmail.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
