New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net: add FlagRunning as network interface flag #29991

Open
brutella opened this Issue Jan 30, 2019 · 6 comments

Comments

Projects
None yet
5 participants
@brutella
Copy link

brutella commented Jan 30, 2019

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.

@gopherbot gopherbot added this to the Proposal milestone Jan 30, 2019

@gopherbot gopherbot added the Proposal label Jan 30, 2019

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Jan 30, 2019

CC @mikioh

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

ianlancetaylor commented Jan 30, 2019

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

@brutella

This comment has been minimized.

Copy link
Author

brutella commented Feb 1, 2019

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

@rsc

This comment has been minimized.

Copy link
Contributor

rsc commented Feb 6, 2019

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.

@rsc rsc changed the title proposal: net: add FlagRunning as network interface flag net: add FlagRunning as network interface flag Feb 6, 2019

@rsc rsc modified the milestones: Proposal, Go1.13 Feb 6, 2019

@mikioh

This comment has been minimized.

Copy link
Contributor

mikioh commented Feb 7, 2019

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

This comment has been minimized.

Copy link
Contributor

mikioh commented Feb 12, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment