> 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. > 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'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. -- 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
