svn commit: r205024 - head/sys/net

[Robert N. M. Watson]

On Mar 12, 2010, at 7:52 AM, Qing Li wrote:

>> Is there any way we can pick up via an assertion that an interface driver has failed to implement this functionality? This has never been a historic requirement, so I suspect there are a lot of drivers floating around that fail to meet the requirement. Also, is this for IFT_ETHER only, or also other link types?
> 
> Not sure if I get the assertion suggestion. How would an assertion help here ?

I think my proposal is similar to what Juli is suggesting:

- Define a new interface capability for link state detection.
- If a packet is sent or received on the interface, the capability is set, but the link state hasn't been set, panic.
- If a packet is sent received on the interface, the capability isn't set, and the link state has been set, panic.

That way the system blows up nicely and immediately, rather than dhclient simply never working, etc. Also, that way, testing for link state support is done at a point when we know the interface is live (a packet is sent or received).

Finally, it means that code interested in link state isn't testing for one of (n) IFT_ types it thinks should have link state, but instead testing specifically whether the driver declares link state support. Of course, then you have to decide how to behave if a configured interface ECMP is running on doesn't support link state: the answer there is probably to assume it is always up, which would make this work for all those drivers that current fail to implement it. And if the hardware can't support link state, which some historic (and perhaps future) link types can't, things still work.

Robert