daniel-p-carvalho commented on PR #20519: URL: https://github.com/apache/nuttx/pull/20519#issuecomment-6097627391
Hi @zhhyu7, thanks for the suggestion. I agree that a `netdev_lowerhalf_s`-based bridge under `drivers/net/bridge` would be the cleaner design: br0 would be a regular lowerhalf netdev, the upper half would handle RX/TX and locking, and I could drop `BRIDGE_POLL` in devif and some of the hooks. My hesitation is driver coverage. A quick count of the current tree (files, so only approximate): - **Lowerhalf** (`netdev_lower_register`): about 22 files. In `arch/` that is 4 in risc-v, 2 in xtensa, and 1 each in arm, mips and sim. The rest is under `drivers/` (net, can, virtio, vhost, usb). - **Legacy** (`netdev_register`): about 85 files. `arch/arm` alone has 40, and there are 10 in risc-v and 3 in arm64. `drivers/net` has 12, plus wireless, usb and a few board-level drivers. So most of the in-tree Ethernet MACs (STM32, SAMV7, i.MX RT, Kinetis, PIC32MZ, ...) are still legacy. A lowerhalf-only bridge would leave the main use case of this PR unsupported: Ethernet<->Wi-Fi on the PIC32MZ, whose Ethernet driver is legacy while its Wi-Fi driver is lowerhalf. To support it I would first have to migrate `pic32mz_ethernet` to lowerhalf, which is a separate PR and can only be tested on hardware. So my proposal is to keep the current approach in this PR: a hook in the upper half (all ethertypes) and in `ipv4_input`/`ipv6_input`/`arp_input` for legacy drivers (IP/ARP only). It stays compatible with the design you describe. As drivers move to lowerhalf, the legacy path can be removed and the bridge can become a lowerhalf driver in `drivers/net/bridge`. If you and the other maintainers prefer lowerhalf-only now, I can restructure the PR that way. In that case I would port `pic32mz_ethernet` first and document that legacy drivers are not supported. Which direction makes more sense for the project? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
