net: add FlagRunning as network interface flag

[brutella]

FlagUp doesn't tell if for example an ethernet cable is physically attached to a network interface.
According to the IFF_UP vs IFF_RUNNING answer, the flag IFF_RUNNING actually does that.
(I did not verify this.)

I propose to add net.FlagRunning to know if a network interface is operational.

[ianlancetaylor]

CC @mikioh

[ianlancetaylor]

Looks like reporting just IFF_UP, not IFF_RUNNING, dates back to https://codereview.appspot.com/4437087 .

[brutella]

Reading through the code review and I couldn't find anything that speaks against supporting IFF_RUNNING.

[rsc]

It seems like we should have the bit since it's part of the standard network API.
(Here's a stack overflow explaining the difference: https://stackoverflow.com/questions/11679514/what-is-the-difference-between-iff-up-and-iff-running).

Accepting.

[mikioh]

The current set of net.Flags are chosen from the following criteria:

• platform agnostic; we don't want to see an issue like FlagX doesn't work well on operating system Y,
• peripheral or driver agnostic; the same as above,
• management view agnostic; each network/interface stack implementation differs between operating systems and de facto/de jure standards.

IIUC, IFF_RUNNING was introduced in BSD variants to represent some state of the peripheral driver, then Linux introduced and changed the meaning to represent the operational status of the network interface described in RFC 2863. Windows directly shows the operational status. Also even on Linux, IFF_RUNNING might not cover RFC 2863 perfectly, depending on the interface stack (e.g., virtual bridge interface over ethernet) and the peripheral (e.g., 100Gbps ethernet, perhaps, nowadays can we see lane-related stuff/BIP without using I2C GPIO?).

My recommendation as follows:

1. if you really need to read out the physical/link-layer information, the safe and correct way still would be to use operating system-specific facilities (e.g., netlink on Linux, route on BSDs) and peripheral-specific facilities (e.g., communication between microcode in the transceiver), the same as many appliances do.
2. if you really love to have something a bit inaccurate but perhaps useful information in the net package, it's better to add a new API like os.FileInfo and os.FileInfo.Sys rather than trying to abstract platform, driver and management things. There's a similar request: #17445.

[mikioh]

http://golang.org/cl/162037 is a counter proposal.