link: Support specifying arbitrary LinkMessage for RTM_DELLINK

[cathay4t]

In order to support deleting bridge VLAN information, this patch
introduced LinkHandle::del_with_message() allowing sending arbitrary
LinkMessage for the RTM_DELLINK call.

Example code updated with bridge VLAN deletion function.

[gemini-code-assist]

Summary of Changes

Hello @cathay4t, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the rtnetlink library by providing a more flexible and powerful mechanism for deleting network link configurations. By allowing users to specify a custom LinkMessage during a deletion call, it enables handling complex deletion scenarios, such as removing bridge VLAN information. The accompanying example has been updated to clearly demonstrate this new capability.

Highlights

• New API for Link Deletion: Introduced LinkHandle::del_with_message() which allows specifying an arbitrary LinkMessage when performing an RTM_DELLINK operation, providing greater flexibility for link deletion.
• Bridge VLAN Deletion Support: This new API specifically enables the deletion of bridge VLAN information, addressing a previous limitation in the library's capabilities.
• Updated Example: The examples/set_bridge_vlan.rs example has been updated to demonstrate the usage of the new del_with_message() function for deleting bridge VLAN configurations.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces LinkHandle::del_with_message() to allow sending an arbitrary LinkMessage for RTM_DELLINK operations, which is demonstrated by adding bridge VLAN deletion to an example. The core logic change is sound. My review includes a high-priority comment on an API inconsistency in del_with_message that should be addressed, as it likely prevents the code from compiling as-is and deviates from the established API pattern. I've also included a medium-priority suggestion to refactor duplicated code in the updated example for better clarity and maintainability.

[gemini-code-assist]

There's significant code duplication between this function (del_bridge_vlan) and set_bridge_vlan. The logic for building the LinkMessage for both the port and the bridge is identical in both functions.

To improve maintainability and reduce redundancy, consider extracting the message creation logic into separate helper functions. This would make the example cleaner and easier to understand.

For example:

fn build_port_vlan_msg(port_index: u32) -> rtnetlink::packet_route::link::LinkMessage {
    LinkBridgeVlan::new(port_index)
        .vlan(10, BridgeVlanInfoFlags::Pvid)
        .vlan_range_start(20, BridgeVlanInfoFlags::empty())
        .vlan_range_end(30, BridgeVlanInfoFlags::empty())
        .build()
}

fn build_bridge_self_vlan_msg(bridge_index: u32) -> rtnetlink::packet_route::link::LinkMessage {
    LinkBridgeVlan::new(bridge_index)
        .bridge_self()
        .vlan(40, BridgeVlanInfoFlags::Pvid)
        .vlan_range_start(50, BridgeVlanInfoFlags::empty())
        .vlan_range_end(60, BridgeVlanInfoFlags::empty())
        .build()
}

Then you could simplify del_bridge_vlan (and set_bridge_vlan) to use these helpers.

[cathay4t]

This is over optimization considering this is example code. I think keeping function simple is more important.