On Thu, May 4, 2023 at 10:55 PM Jens Axboe <axboe@xxxxxxxxx> wrote: > > That potentially works for null_blk, but it would not work for anything > that people actually depend on. In other words, anything that isn't > null_blk. And I don't believe we'd be actively discussing these bindings > if just doing null_blk is the end goal, because that isn't useful by > itself, and at that point we'd all just be wasting our time. In the real > world, once we have just one actual driver using it, then we'd be > looking at "this driver regressed because of change X/Y/Z and that needs > to get sorted before the next release". And THAT is the real issue for > me. So a "rust keeps up or it breaks" model is a bit naive in my > opinion, it's just not a viable approach. In fact, even for null_blk, > this doesn't really fly as we rely on blktests to continually vet the > sanity of the IO stack, and null_blk is an integral part of that. But `null_blk` shouldn't be affected, no? The Rust abstractions can be behind an explicit "experimental" / "broken" / "compile-test only" gate (or similar) in the beginning, as a way to test how much maintenance it actually requires. In such a setup, Andreas could be the one responsible to keep them up to date in the beginning. That is, in the worst case, a kernel release could happen with the Rust side broken -- that way `null_blk` is not impacted. That is why a separate `MAINTAINERS` entry may be interesting if you want to keep e.g. the `S:` level separate (though Andreas, I think, may be able to do "Supported" at this time). When the first real driver comes, a similar approach could be repeated, to buy some more time too. Cheers, Miguel
