> >> As far as usnic, it seems like its the driver that has been > forgotten about. > >> I see 3 commits in 2018. I'm not saying it's important or not, > that's > >> another debate for another thread. > > > > There are alot more than three, and all of them are from non-Cisco > > people trying to maintain this driver. Many are mine. > > > > This is not a plus, it shows why this approach is a burden on the > rest > > of the community. > > That's the point I was beating around the bush about. As a community > we don't need any fire and forget drivers where it gets upstreamed and > abandoned. usNIC is a very simple device. I'm not sure you can assume that it isn't used or was forgotten just because it's done. I do know that it is actively maintained on the user space side, even if it doesn't need anything more from the kernel. I agree that exposing usNIC through verbs was wrong. However, as a device, I don't see that it's that functionally different than QIB, truescale, or hfi1. None of those are verbs devices, and throwing a software verbs implementation over them doesn't really change that. > Now if we do want to say a driver must support verbs it can't be > wishy-washy. We should specify exactly the set of verbs that must be > supported. The IBTA has the notion of some mandatory verbs right, so > should that be the low bar? Should we whittle that down further? If you go this path, rename the subsystem to linux-verbs or linux-ibverbs. However, if the subsystem will support exposing non-verbs interfaces (usnic, psm, psm2), then I disagree with placing a requirement that the driver must also provide a software implementation of verbs over it. - Sean
