Jakub Kicinski wrote: > On Thu, 4 Apr 2024 12:22:02 -0700 Alexander Duyck wrote: > > The argument itself doesn't really hold water. The fact is the Meta > > data centers are not an insignificant consumer of Linux, > > customer or beneficiary ? > > > so it isn't as if the driver isn't going to be used. This implies > > some lack of good faith from Meta. > > "Good faith" is not a sufficient foundation for a community consisting > of volunteers, and commercial entities (with the xz debacle maybe even > less today than it was a month ago). As a maintainer I really don't want > to be in position of judging the "good faith" of corporate actors. > > > I don't understand that as we are > > contributing across multiple areas in the kernel including networking > > and ebpf. Is Meta expected to start pulling time from our upstream > > maintainers to have them update out-of-tree kernel modules since the > > community isn't willing to let us maintain it in the kernel? Is the > > message that the kernel is expected to get value from Meta, but that > > value is not meant to be reciprocated? Would you really rather have > > us start maintaining our own internal kernel with our own > > "proprietary goodness", and ask other NIC vendors to have to maintain > > their drivers against yet another kernel if they want to be used in > > our data centers? > > Please allow the community to make rational choices in the interest of > the project and more importantly the interest of its broader user base. > > Google would also claim "good faith" -- undoubtedly is supports > the kernel, and lets some of its best engineers contribute. > Did that make them stop trying to build Fuchsia? The "good faith" of > companies operates with the limits of margin of error of they consider > rational and beneficial. > > I don't want to put my thumb on the scale (yet?), but (with my > maintainer hat on) please don't use the "Meta is good" argument, because > someone will send a similar driver from a less involved company later on > and we'll be accused of playing favorites :( Plus companies can change > their approach to open source from "inclusive" to "extractive" > (to borrow the economic terminology) rather quickly. > I'll throw my $.02 in. In this case you have a driver that I only scanned so far, but looks well done. Alex has written lots of drivers I trust he will not just abondon it. And if it does end up abondoned and no one supports it at some future point we can deprecate it same as any other driver in the networking tree. All the feedback is being answered and debate is happening so I expect will get a v2, v3 or so. All good signs in my point. Back to your point about faith in a company. I don't think we even need to care about whatever companies business plans. The author could have submitted with their personal address for what its worth and called it drivers/alexware/duyck.o Bit extreme and I would have called him on it, but hopefully the point is clear. We have lots of drivers in the tree that are hard to physically get ahold of. Or otherwise gated by paying some vendor for compute time, etc. to use. We even have some drivers where the hardware itself never made it out into the wild or only a single customer used it before sellers burned it for commercial reasons or hw wasn't workable, team was cut, etc. I can't see how if I have a physical NIC for it on my desk here makes much difference one way or the other. 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? 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. 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? 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 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. Thanks, John
