On Sun, Mar 21, 2021 at 01:21:14PM -0400, Dennis Dalessandro wrote: > Maybe that's something that should be explored. Isn't this along the lines > of stuff we talked about with the verbs 2.0 stuff, or whatever we ended up > calling it. I think verbs 2.0 turned into the ioctl uapi stuff, I don't remember anymore. > > > We should be trying to get things upstream, not putting up walls when people > > > want to submit new drivers. Calling code "garbage" [1] is not productive. > > > > Putting a bunch of misaligned structures and random reserved fields > > *is* garbage by the upstream standard and if I send that to Linus I'll > > get yelled at. > > Not saying you should send this to Linus. I'm saying we should figure out a > way to make it better and insulting people and their hard work isn't > helping. No - you've missed what happened here. Todd responded very fast and explained - Intel *knowingly* sent code that was sub-standard as some calculated attempt to make Intel's life maintaining their out of tree drivers easier. This absoultely needs strong language as I can't catch everything and people need to understand there are real consequences to violating the community trust in this way! > No one is suggesting to compromise the upstream world. I'm not sure what you mean - what could upstream do to in any way change the situation other than compromising on what will be merged? > There is a bigger picture here. The answer for this driver may just > be take out the reserved stuff. That's pretty simple. The bigger > question is how do we deal with non-upstream code. It can't be a > problem unique to the RDMA subsystem. How do others deal with it? The kernel community consensus is that upstream code is on its own. We don't change the kernel to accomodate out-of-tree code. If the kernel changes and out of tree breaks nobody cares. Over a long time it has been proven that this methodology is a good way to effect business change to align with the community consensus development model - eventually the costs of being out of tree have bad ROI and companies align. > That is completely not what I meant at all. I mean we should be > trying to get rid of the proprietary, and out of tree stuff. It > doesn't at all imply to fling crap against the wall and hope it > sticks. We should be encouraging vendors to submit their code and > work with them to get it in shape. Well, I am working on something like 4-5 Intel series right now, and it sometimes does feel like flinging. Have you seen Greg KH's remarks that he won't even look at Intel patches until they have internal expert sign off? > not encourage that behavior. Vendors should say I want to submit my code to > the Linux kernel. Not eh, it's too much of a hassle and kernel people are > jerks, so we'll just post it on our website. There is a very, very fine line between "working with the community" and "the community will provide free expert engineering work to our staff". > To be fair it is sent as RFC. So to me that says they know it's a ways off > from being ready to be included and are starting the process early. I'm not sure why it is RFC. It sounds like it is much more than this if someone has already made a version with links to the NVIDIA GPU driver and has reached a point where they care about ABI stablility? Jason
