On Thu, Apr 4, 2024 at 2:59 PM John Fastabend <john.fastabend@xxxxxxxxx> wrote: > > Jakub Kicinski wrote: > > On Thu, 4 Apr 2024 12:22:02 -0700 Alexander Duyck wrote: > > > 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 advantage of Meta not selling it publicly at this time is that Meta is both the consumer and the maintainer so if a kernel API change broke something Meta would be responsible for fixing it. It would be Meta's own interest to maintain the part, and if it breaks Meta would be the only one impacted assuming the breaking change at least builds. So rather than "good faith", maybe I should have said "motivated self interest". It seems like the worst case scenario would actually be some commercial product being sold. Worse yet, one with proprietary bits such as firmware on the device. Should commercial vendors be required to provide some sort of documentation proving they are dedicated to their product and financially stable enough to maintain it for the entire product life cycle? What if the vendor sells some significant number of units to Linux users out there, and then either goes under, gets acquired, and/or just decides to go in a new direction. In that scenario we have the driver unmaintained and consumers impacted, but the company responsible for it has no motivation to address it other than maybe negative PR. > 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. This is what I was referring to as being "arbitrary and capricious". The issue is what would we define as a NIC being for sale commercially. Do we have to support a certain form factor, sell it for a certain price, or sell a certain quantity? If anything maybe we should look more at something like a blast radius in terms of inclusion. If this were to go wrong, how could it go wrong and who would be impacted. > 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 Thanks for your reply. I had started a reply, but you probably worded this better than I could have. Thanks - Alex
