Asahi Lina开发的苹果M1显示驱动程序可以正常工作了On the Rust side, have to say I'm super pleased experience writing a driver with my like this in Rust! I've had zero concurrency issues (and the driver uses fine-grained locking, there's no big driver lock) - once single processes worked, running multiple apps concurrently just worked. Also zero memory leaks, dangling CPU or GPU pointers, use-after / frees / free order mistakes, or anything like that! The only memory corruption issues I ran into were either fundamental mistakes in my unsafe DRM abstraction or core GPU memory management code, or happened from the GPU side (there's an issue with TLB invalidation, that's what the ugly workaround is for). I feel like Rust encourages good driver design and then the compiler goes a long way towards making the resulting code correct. All in all didn't really have that many bugs to fix, mostly just logic issues (both because I'm new to DRM and because the GPU interface is all reverse engineered and we're still working out the details).
The workaround for the GPU-side TLB inval issue has a large performance hit, but without that, kmscube does run at 1000+ FPS, and that's with a lot of suboptimal components that will be improved over time (e.g. my current allocator allocates/maps/unmaps/frees tons of little GPU structures per frame), sO I'm also very optimistic about the performance aspect! The only major Rust issue ran into is the lack of placement new, which I ended up working around with a very ugly place!() macro (it still has a soundness issue too, need to fix it to drop things if initialization fails halfway through). Without that, was quickly overflowing the kernel stacks (which is particularly ugly to debug without CONFIG_VMAP_STACK, which didn't have set at first...). With the macro though, the stack frames are under control enough that there's no issue, but I'd really love to see core language support for this. I think it's really necessary for kernel/embedded development.
原文作者:Rust语言中文社区;如有侵权,请联系管理员删除。