Skip to content

Conversation

yonatan-linik
Copy link

No description provided.

@yonatan-linik
Copy link
Author

@cathay4t I would like to help if that's fine by you.
Let me know if you want me to design this differently, or if you want me to add support for more interface types before merging.

@yonatan-linik yonatan-linik force-pushed the support-detailed-link-show branch 3 times, most recently from ee52b2b to cdf6443 Compare July 26, 2025 18:37
@cathay4t
Copy link
Member

Any help is welcome.

Could you split this PR into two patches:

  1. skeleton with zero interface type supports, no test case required.
  2. Add support of loopback interface support. This patch can be used as example when people adding more interface supports later. The test case should be focusing on asserting ip -d link show lo.

yonatan-linik and others added 2 commits August 4, 2025 18:05
Now supporting:
promiscuity
min_mtu
max_mtu
inet6_addr_gen_mode
num_tx_queues
num_rx_queues
gso_max_size
gso_max_segs

Also adds skeleton for specific details
Loopback interfaces don't seem to have specific properties unique to
them.
These changes are added as a base example for other interface types.
@yonatan-linik yonatan-linik force-pushed the support-detailed-link-show branch from cdf6443 to 76ec769 Compare August 4, 2025 15:30
@yonatan-linik
Copy link
Author

yonatan-linik commented Aug 4, 2025

@cathay4t Done.

I am not sure about this design, I think some of the type-specific properties might come between the "common" properties.
Maybe it is best to just add all properties without separating to the different interface types (just using Option)?
If a property isn't relevant for some interface we won't get it from the kernel anyway, right?

I also have other changes for adding support for down-link and link-netns, should I open another PR?

@yonatan-linik yonatan-linik marked this pull request as ready for review August 8, 2025 13:26
@cathay4t
Copy link
Member

cathay4t commented Aug 20, 2025

@cathay4t Done.

I am not sure about this design, I think some of the type-specific properties might come between the "common" properties. Maybe it is best to just add all properties without separating to the different interface types (just using Option)? If a property isn't relevant for some interface we won't get it from the kernel anyway, right?

You may have

struct IfaceDetail {
  base: BaseInterfaceDetail,
  bond: Option<BondConfig>,
  bridge: Option<BridgeConfig>
}

I also have other changes for adding support for down-link and link-netns, should I open another PR?

New PR please.

Please fix the CI failure also.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants