On Thu, 04 Apr 2024 14:59:33 -0700 John Fastabend wrote: > The alternative is much worse someone builds a team of engineers locks > them up they build some interesting pieces and we never get to see it > because we tried to block someone from opensourcing their driver? Opensourcing is just one push to github. There are guarantees we give to upstream drivers. > Eventually they need some kernel changes and than we block those too > because we didn't allow the driver that was the use case? This seems > wrong to me. The flip side of the argument is, what if we allow some device we don't have access to to make changes to the core for its benefit. Owner reports that some changes broke the kernel for them. Kernel rules, regression, we have to revert. This is not a hypothetical, "less than cooperative users" demanding reverts, and "reporting us to Linus" is a reality :( Technical solution? Maybe if it's not a public device regression rules don't apply? Seems fairly reasonable. > Anyways we have zero ways to enforce such a policy. Have vendors > ship a NIC to somebody with the v0 of the patch set? Attach a picture? GenAI world, pictures mean nothing :) We do have a CI in netdev, which is all ready to ingest external results, and a (currently tiny amount?) of test for NICs. Prove that you care about the device by running the upstream tests and reporting results? Seems fairly reasonable. > Even if vendor X claims they will have a product in N months and > than only sells it to qualified customers what to do we do then. > Driver author could even believe the hardware will be available > when they post the driver, but business may change out of hands > of the developer. > > I'm 100% on letting this through assuming Alex is on top of feedback > and the code is good. I'd strongly prefer if we detach our trust and respect for Alex from whatever precedent we make here. I can't stress this enough. IDK if I'm exaggerating or it's hard to appreciate the challenges of maintainership without living it, but I really don't like being accused of playing favorites or big companies buying their way in :( > I think any other policy would be very ugly to enforce, prove, and > even understand. Obviously code and architecture debates I'm all for. > Ensuring we have a trusted, experienced person signed up to review > code, address feedback, fix whatever syzbot finds and so on is also a > must I think. I'm sure Alex will take care of it. "Whatever syzbot finds" may be slightly moot for a private device ;) but otherwise 100%! These are exactly the kind of points I think we should enumerate. I started writing a list of expectations a while back: Documentation/maintainer/feature-and-driver-maintainers.rst I think we just need something like this, maybe just a step up, for non-public devices..
