On Fri, Jul 19, 2024 at 01:24:10PM -0300, Daniel Almeida wrote: > > +The most effective way to prevent issues in ``unsafe`` code is to just not write ``unsafe`` code in > > +the first place. That is why minimizing the amount of ``unsafe`` code is very important. For > > +example, drivers are not allowed to directly interface with the C side. Instead of directly > > +communicating with C functions, they interact with Rust abstractions. This concentrates the usage > > +of ``unsafe`` code, making it easy to fix issues, since only the abstraction needs to be fixed. > > +Abstractions also allow taking advantage of other Rust language features. Read more in > > +:ref:`rust-abstractions`. > > This is something that I think we should discuss at Kangrejos. I do not think > that we should set in stone that the kernel crate is the only place where > unsafe code is acceptable. > > I am in no way disagreeing with the use of safe abstractions, but I think we > should have abstractions where they make sense. This is the case in the vast > majority of times, but not in *all* of them. > > A simple example is a MMIO read or write. Should a driver be forbidden to call > readX/writeX for an address it knows to be valid? How can you possibly write an > abstraction for this, when the driver is the only one aware of the actual > device addresses, and when the driver author is the person with actual access > to the HW docs? We can easily build abstractions that ensure that the address a driver is trying to access is mapped properly, such that you can't have accidential out-of-bound accesses. Those can be implemented by the corresponding subsystem / bus that the resource originates from. In fact, we already have abstractions for that on the way, a generic I/O abstraction [1] as base implementation and a specific abstraction for PCI bars [2]. Of course, if the MMIO region comes from let's say the device tree, we still have to assume that the information in the DT is correct, but the driver does not need unsafe code for this. [1] https://lore.kernel.org/rust-for-linux/20240618234025.15036-8-dakr@xxxxxxxxxx/ [2] https://lore.kernel.org/rust-for-linux/20240618234025.15036-11-dakr@xxxxxxxxxx/ > > If a driver is written partially in Rust, and partially in C, and it gets a > pointer to some kcalloc’d memory in C, should It be forbidden to use unsafe > in order to build a slice from that pointer? How can you possibly design a > general abstraction for something that is, essentially, a driver-internal API? That sounds perfectly valid to me.
