On Mon, Mar 04, 2019 at 11:47:00AM +0100, Antoine Tenart wrote: > Hi Florian, > > I agree having a per-driver behaviour is not something we want. As I > understand it, there is no behaviour enforced currently regarding this > matter. I agree both cases have their pros and cons: > - It's weird to have an interface reporting being UP when it's not > really.
What about when an interface is listening for wake-on-lan packets? Let's say board 1 is powered down and has WoL enabled. Board 2 is as per your configuration. Board 2's interface reports that the link is up. Most of the packets that would be sent out the interface end up disappearing into a black hole in the same way as your original scenario. How is this "weird" ? There are many cases where exactly this happens - you are trying to make one particular scenario behave "better" without considering whether it's possible with all or even the majority of scenarios. The only case where what you're suggesting makes sense is a point-to- point link between two systems, which is not the norm. More than that, when board 1 boots, initially the link will be up from reset. When the kernel eventually boots with your patch, the link will then go down until board 1 configures the interface. So, board 2 sees that the interface comes up, and could assume that board 1 is alive and well - but it isn't because (eg) it's in the boot loader. Basically, what I'm pointing out is that even in your minority scenario, reasoning that board 2 should not see "link up" status until board 1's interface is configured is not reasonable. The link status is about the physical connectivity on the local interface, it is not about the link between the interfaces on the two machines. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
