| Message ID | 20230710073703.147351-1-fujita.tomonori@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Rust abstractions for network device drivers | expand |
On Mon, 10 Jul 2023 16:36:58 +0900 FUJITA Tomonori wrote: > This patchset adds minimum Rust abstractions for network device > drivers and an example of a Rust network device driver, a simpler > version of drivers/net/dummy.c. > > The major change is a way to drop an skb (1/5 patch); a driver needs > to explicitly call a function to drop a skb. The code to let a skb > go out of scope can't be compiled. > > I dropped get_stats64 support patch that the current sample driver > doesn't use. Instead I added a patch to update the NETWORKING DRIVERS > entry in MAINTAINERS. I'd like to double down on my suggestion to try to implement a real PHY driver. Most of the bindings in patch 3 will never be used by drivers. (Re)implementing a real driver will guide you towards useful stuff and real problems.
On Mon, Jul 10, 2023 at 11:29:52AM -0700, Jakub Kicinski wrote: > On Mon, 10 Jul 2023 16:36:58 +0900 FUJITA Tomonori wrote: > > This patchset adds minimum Rust abstractions for network device > > drivers and an example of a Rust network device driver, a simpler > > version of drivers/net/dummy.c. > > > > The major change is a way to drop an skb (1/5 patch); a driver needs > > to explicitly call a function to drop a skb. The code to let a skb > > go out of scope can't be compiled. > > > > I dropped get_stats64 support patch that the current sample driver > > doesn't use. Instead I added a patch to update the NETWORKING DRIVERS > > entry in MAINTAINERS. > > I'd like to double down on my suggestion to try to implement a real > PHY driver. Most of the bindings in patch 3 will never be used by > drivers. (Re)implementing a real driver will guide you towards useful > stuff and real problems. And I'd recommend that we not take any more bindings without real users, as there seems to be just a collection of these and it's hard to actually review them to see how they are used... thanks, greg k-h
Hi, On Mon, 10 Jul 2023 11:29:52 -0700 Jakub Kicinski <kuba@kernel.org> wrote: > On Mon, 10 Jul 2023 16:36:58 +0900 FUJITA Tomonori wrote: >> This patchset adds minimum Rust abstractions for network device >> drivers and an example of a Rust network device driver, a simpler >> version of drivers/net/dummy.c. >> >> The major change is a way to drop an skb (1/5 patch); a driver needs >> to explicitly call a function to drop a skb. The code to let a skb >> go out of scope can't be compiled. >> >> I dropped get_stats64 support patch that the current sample driver >> doesn't use. Instead I added a patch to update the NETWORKING DRIVERS >> entry in MAINTAINERS. > > I'd like to double down on my suggestion to try to implement a real > PHY driver. Most of the bindings in patch 3 will never be used by > drivers. (Re)implementing a real driver will guide you towards useful > stuff and real problems. You meant reimplementing one of drivers in drivers/net/phy in Rust (with Rust abstractions for PHY drivers)? Even the approach, we would get hit the same problem? Replacing an existing working driver in C doesn't make sense much thus the abstractions cannot be merged until someone want to implement a driver in Rust for new PHY hardware. Or you think that PHY drivers (and probably the abstractions) are relatively simple so merging the abstractions for them is acceptable without a real driver (we could put a real drivers under samples/rust/)? thanks,
> Or you think that PHY drivers (and probably the abstractions) are > relatively simple so merging the abstractions for them is acceptable > without a real driver (we could put a real drivers under > samples/rust/)? PHY drivers are much simpler than Ethernet drivers. But more importantly, the API to the rest of network stack is much much smaller. So a binding for a sample driver is going to cover a large part of that API, unlike your sample Ethernet driver binding which covers a tiny part of the API. The PHY binding is then actually useful, unlike the binding for Ethernet. As for reimplementing an existing driver, vs a new driver for hardware which is currently unsupported, that would depend on you. You could reach out to some vendors and see if they have devices which are missing mainline drivers. See if they will donate an RDK and the datasheet in return for a free driver written in Rust. Whole new drivers do come along reasonably frequently, so there is probably scope for a new driver. Automotive is a big source of new code and devices at the moment. Andrew
Hi, On Tue, 11 Jul 2023 15:17:33 +0200 Andrew Lunn <andrew@lunn.ch> wrote: >> Or you think that PHY drivers (and probably the abstractions) are >> relatively simple so merging the abstractions for them is acceptable >> without a real driver (we could put a real drivers under >> samples/rust/)? > > PHY drivers are much simpler than Ethernet drivers. But more > importantly, the API to the rest of network stack is much much > smaller. So a binding for a sample driver is going to cover a large > part of that API, unlike your sample Ethernet driver binding which > covers a tiny part of the API. The PHY binding is then actually > useful, unlike the binding for Ethernet. Point taken, I work on PHY drivers first. > As for reimplementing an existing driver, vs a new driver for hardware > which is currently unsupported, that would depend on you. You could > reach out to some vendors and see if they have devices which are > missing mainline drivers. See if they will donate an RDK and the > datasheet in return for a free driver written in Rust. Whole new > drivers do come along reasonably frequently, so there is probably > scope for a new driver. Automotive is a big source of new code and > devices at the moment. Understood. Let me reseach the existing drivers to think about that. Thanks,
This patchset adds minimum Rust abstractions for network device drivers and an example of a Rust network device driver, a simpler version of drivers/net/dummy.c. The major change is a way to drop an skb (1/5 patch); a driver needs to explicitly call a function to drop a skb. The code to let a skb go out of scope can't be compiled. I dropped get_stats64 support patch that the current sample driver doesn't use. Instead I added a patch to update the NETWORKING DRIVERS entry in MAINTAINERS. Changes since v1 [1]: - a driver must explicitly call a function to drop a skb. - simplify the code (thanks to Benno Lossin). - update MAINTAINERS file. [1] https://lwn.net/ml/netdev/20230613045326.3938283-1-fujita.tomonori@gmail.com/ FUJITA Tomonori (5): rust: core abstractions for network device drivers rust: add support for ethernet operations rust: add methods for configure net_device samples: rust: add dummy network driver MAINTAINERS: add Rust network abstractions files to the NETWORKING DRIVERS entry MAINTAINERS | 2 + rust/bindings/bindings_helper.h | 3 + rust/helpers.c | 23 ++ rust/kernel/lib.rs | 3 + rust/kernel/net.rs | 5 + rust/kernel/net/dev.rs | 598 ++++++++++++++++++++++++++++++++ samples/rust/Kconfig | 13 + samples/rust/Makefile | 1 + samples/rust/rust_net_dummy.rs | 75 ++++ scripts/Makefile.build | 2 +- 10 files changed, 724 insertions(+), 1 deletion(-) create mode 100644 rust/kernel/net.rs create mode 100644 rust/kernel/net/dev.rs create mode 100644 samples/rust/rust_net_dummy.rs base-commit: d2e3115d717197cb2bc020dd1f06b06538474ac3