@lina @Sobex the current model is fine for C developers trying to add simple things or fix bugs and so on, but when large architectural changes are needed (aka you welcome a new language in the codebase) it's definitely a major point of friction and literal slowdown
Regarding reviews, IIRC, the first time a network driver was sent to netdev, the first reply arrived 48h later at least and it was an apology that nobody was reviewing (i could pull the exact lore links when i'm back at a computer): there was just nobody available to review Rust. Concurring with that (and I'm sorry i'm putting my academic hat on because this is exactly what I'm focused on atm), Hongyu Li et al0 found that "RFL is bottlenecked by code review but not by code development" (insight 3), and it's pretty easy to see anytime you get an actual driver sent to the LKMLs for reviews, which is somewhat rare these days
i remember seeing your patchsets dying and your presence in the LKMLs diminishing, and it was quite sad, because of all the work put in it :( i'm also very interested in making abstractions, but finding an end user without paying for obscure or brand new hardware is so hard in net, so i just can't contribute anything, and i'm not alone...
Hopefully things fare better in the future but it's going to need a lot of change of mind from a lot of people..
@SharpLimefox @Sobex Honestly the thing that has burned me out the most has been the scheduler saga and seeing how slow the core Device/platform driver stuff (+ the device ID pain) is moving (due to pushback from upstream mostly). I don't want to take on that work myself because I didn't write the original code and I don't fully understand the nuances of the device binding cycle/lifetimes and how that was originally designed for the Rust abstractions (+ my GPU driver literally can't support rebind due to firmware limitations so it's a terrible test/demo case of how to do all that properly). But I depend on that to get anything done...
Once platform devices are supported I'll go back to sending my stuff and I hope it'll be a lot less blocked after that. For better or worse the approach ends up being "don't depend on subsystems where upstream doesn't want to cooperate and will stall, if you can help it"... I think I have a pretty good idea of what those are so things should move forward. I hope...
@SharpLimefox @Sobex Honestly the thing that has burned me out the most has been the scheduler saga and seeing how slow the core Device/platform driver stuff (+ the device ID pain) is moving (due to pushback from upstream mostly). I don't want to take on that work myself because I didn't write the original code and I don't fully understand the nuances of the device binding cycle/lifetimes and how that was originally designed for the Rust abstractions (+ my GPU driver literally can't support rebind...