Thu, Apr 04, 2024 at 11:59:33PM CEST, john.fastabend@xxxxxxxxx wrote: >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? Come on. Are you kidding? Isn't this case crystal clear? >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. You are for some reason making this submission very personal on Alex. Just to be clear, this has nothing to do with Alex. > >Thanks, >John
