On Mon, Nov 20, 2017 at 9:41 PM, Jason Gunthorpe <jgg@xxxxxxxx> wrote: > Well, I would like to know the issues as well, as I've already said I > think they should be described in the commit message. > But also, at the RFC stage the onus is on other people, particularly > people that want to keep the feature, to explain where it is being > used and why.. we did it to allow user space track rdma-cm connections through the rdma subsystem netlink infra-structure, e.g one can come up with netstat like reporting of rdma listeners and connections, this is it! > We need to decide if we drop the RFC and fix the implementation, apply > the the RFC, or add a deprecation printk warning, or something.. right. To my opinion, if there are issues in the implementation, lets fix them, I don't see why remove this implementation and replace it with a new one that does the same thing. > Please try to be productive here and concentrate on adding information > and not nit-picking the process! We all know removing a uapi is a big > deal. Re usage I provided what I know. When a patch is sent to remove code "which has problems" and the author doesn't provide any information on the nature nor the details of the problems after being asked three times - what this has to do with nit picking or processes? it's something totally different, isn't that? Or. -- 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
