net: replace the ethtool external program calls with the `safchain/ethtool` package

[ffromani]

replace the ethtool invocation and related output parsing with the ethtool package which can now provide the same information natively (e.g. the package will NOT call the binary bug it will query the kernel)

Fixes: https://github.com/jaypipes/ghw/issues/317

[ffromani]

test failures are intentional (!!!) to make sure we don't merge without explicit action!

[ffromani]

proposed PR: https://github.com/safchain/ethtool/pull/49

[jak3kaj]

I'm glad to see refactoring with the native Go ethtool library removed many package dependencies and even simplified the code!

If we decide to go this route, I can contribute a PR which refactors #338 #342 to also use github.com/safchain/ethtool.

[ffromani]

I'm glad to see refactoring with the native Go ethtool library removed many package dependencies and even simplified the code!

If we decide to go this route, I can contribute a PR which refactors #338 #342 to also use github.com/safchain/ethtool.

I'm happy there's interest in this approach! The main and only blocker here seems that the upstream project is a bit slowmoving. I'll look for other alternatives. I'm also considering a fork tailored for ghw purposes, but I'm still considering the maintainership costs.

[ffromani]

@jaypipes just wondering: would a minimal ethtool package (perhaps unexported, like in internal/?) tailored for the needs of the project be a welcome addition to ghw? I'd like to move forward here and I'm considering which options we have on the table.

[jaypipes]

@jaypipes just wondering: would a minimal ethtool package (perhaps unexported, like in internal/?) tailored for the needs of the project be a welcome addition to ghw? I'd like to move forward here and I'm considering which options we have on the table.

If there isn't a viable option out there in the open source world that is well-maintained and documented, I'd be perfectly fine doing an internal/ package, yes!

[ffromani]

@jaypipes just wondering: would a minimal ethtool package (perhaps unexported, like in internal/?) tailored for the needs of the project be a welcome addition to ghw? I'd like to move forward here and I'm considering which options we have on the table.

If there isn't a viable option out there in the open source world that is well-maintained and documented, I'd be perfectly fine doing an internal/ package, yes!

perfect, my thoughts exactly. Let me try harder not to have this internal package if we can help it.