On Thu, Feb 12, 2026 at 2:38 PM Maxime Ripard <[email protected]> wrote: > > Hi Alice, > > On Thu, Feb 12, 2026 at 09:16:51AM +0100, Alice Ryhl wrote: > > If you make the raw API unsafe, then that's okay but any use of an > > unsafe API from a driver will receive very hard scrutiny. > > And that's totally fair to me. If drivers want to have a more optimal > but potentially unsafe use of the API, then it should be flagged, > documented and scrutinized. > > > Yes, there are occasionally good reasons to use unsafe from drivers, > > but the entire point of this Rust exercise is to isolate unsafe code > > outside of drivers as much as possible. > > So, aside from the risk of fuckups, are you concerned about something > here? Do you expect that scrutiny to be constly on the maintenance side > of things?
Well I do think it's mostly the risk of mistakes, yes. > I guess what I'm asking is: except for the obvious "review" cost > associated with it, why would that be a probleme if we have, say, a few > dozen drivers using that unsafe API? The reason I wouldn't really suggest the unsafe API is that, if I'm the reviewer of said driver, then my review will be "just use a safe API instead". For example, if you really want explicit inc/dec calls for convenience, we can make a safe API with a counter that returns an error if you decrement more times than you have previously incremented. Or if you prefer something else, I can think of several other safe APIs. > > If Daniel's proposal is inconvenient for some drivers, it would be far > > better to have a third API that is both safe and convenient for those > > drivers. > > Yeah, I guess I was expecting that one to come after we have a few > unsafe drivers using it and we do need to consolidate / make it safe. For most things, we implemented and used the safe API from the very start. I'm not going to say there are never exceptions to that because there *are* exceptions. But I don't really see why clk should be one of them. Alice
