On Mon, May 02, 2016 at 06:29:38PM +0000, Hefty, Sean wrote: > > During the Collab summit I thought we reached a rough consensus that > > these sorts of uAPI changes to the common multi-vendor API would go > > through a more rigorous process and those who are proposing them would > > actively seek a multi-vendor sign off instead of simply dumping them > > on the list. > > I agree that this is the right approach to follow. A Linux maintainer should not be in the position of having to decide on which features merit a uAPI change. In this specific case, all guides were followed. > > > Further, I also thought we reached a rough consensus that we'd shunt > > some of this stuff to the driver specific uAPI channel to reduce this > > continual churn on the common multi-vendor API for currently > > driver-specific features. Drivers can implement their unique features > > and sanely export them through the kernel without so much pain. The > > uAPI 2.0 concepts from all parties have been heavily influenced by > > this idea. > > > > Certainly, if patches cannot attract any review or interest from the > > community as part of the core API then I'd say that is an excellent > > sign they should be shunted to a driver specific channel. > > This is an excellent point. The lack of interest is likely a very good sign that this is a driver specific feature. I don't agree with that point, the lack of discussion doesn't mean that this is driver specific feature. In linux-rdma community, there is a small amount of developers focused on their products and maintainer who doesn't express his opinion. There is general agreement that Mellanox is a leading provider of IB solutions and as a leader it's expected from the company to propose new exciting features which are valuable for the community (general API) and for the customers. In this particular case (RSS), we followed **all** possible guidelines of presenting, discussing and adjusting. It was done in **all** available forums (linux-rdma, OFA and OFVWG). We did it openly without any hiding under "proprietary umbrella", as other companies did during review feedback. > > I'm not sure why there seems to be objection to calling out driver specific features as driver specific and exposing them as such. It seems like the quickest way to get features into the hands of prospective users. We want it beneficial to all participants without proprietary stuff. We don't want to see vendor interfaces proposed and implemented without any review as it was for several drivers in RDMA world. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: Digital signature
