Simple Rust driver that touches real hardware: PR 3/6 #301
Conversation
Add the `PlatformDriver` trait, which driver writers may implement in order to define a platform driver in the kernel. For sake of simplicity and ease of review, `PlatformDriver` consists of two functions for now - `probe()` and `remove()`. Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com>
Implement this in the simplest possible way: by printing a `pr_info` log message on `probe()`/`remove()`. Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com>
|
Absolutely! That will happen in the DrvData step. |
|
This PR should be relatively straightforward, to give everyone involved a well-deserved break :) |
|
That was quick ! Thank you !! 💯 |
|
|
||
| /// Trait for implementers of platform drivers. | ||
| /// | ||
| /// Implement this trait whenever you create a platform driver. |
There was a problem hiding this comment.
Super nit: here you're using the imperative mode "Implement this [...]" while in the functions below you use the indicative mode "Implementers should attempt [...]".
I think we should be consistent and use the same structure in both cases. Personally, I favor the indicative because we are providing information to the reader, not giving them orders. (Though admittedly opinions vary here.)
There was a problem hiding this comment.
Agreed ! And these are probably more important than super-nits. Please do provide that info, so I can improve my "internal algorithm".
| struct RngDriver; | ||
|
|
||
| impl PlatformDriver for RngDriver { | ||
| fn probe(device_id: i32) -> Result { |
There was a problem hiding this comment.
Is it correct to assume that we'll eventually provide more information than device_id?
There was a problem hiding this comment.
Absolutely!! device_id is just a placeholder. Watch this space :)
Simple Rust driver that touches real h/w: step 3 of 6
@alex and @ojeda suggested that #254 should be split into smaller PRs, so they can be reviewed and merged individually.
Roadmap: