On Sat, May 23, 2015 at 7:26 AM, Or Gerlitz <gerlitz.or@xxxxxxxxx> wrote: > On Wed, May 20, 2015 at 8:53 PM, Or Gerlitz <gerlitz.or@xxxxxxxxx> wrote: >> On Wed, May 20, 2015 at 6:11 PM, Yann Droneaud <ydroneaud@xxxxxxxxxx> wrote: >> >>>> But this is whole purpose of the udata framework in uverbs, right? for >>>> each uverb command the vendor user-space library has a well defined >>>> channel to communicate directly with the low level vendor driver >>>> throughout the uverbs channels. >> >>> Uverbs convey information between kernel and userspace drivers to >>> implement verbs for userspace application. I don't think it's designed >>> to allow vendor to add random extensions in the best way with regard to >>> backward/forward compability. >> >> Disagree that this is random extension. The people that designed this >> stack 10y ago (Roland and Co.) looked very nicely forward and realized >> that not all the HW are the same nor can be put 101% under the same >> API with no way out, and hence they came up with udata. >> >> Please state how you see the role of the uverbs udata mechanism. > > Guys, still waiting to hear why you think it's wrong here to use the > mechanism which was built from day-1 for the purpose of allowing the > user-space driver library to communicate with the kernel driver and > pass values in both directions. Jason, ping, it's fair to require that if you made a review argument against the design done here and we've responded about a week ago, saying why this design is valid (e.g goes along the 10y old IB stack udata mechanism and such) -- you would comment on the response and not leave it in the air. 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
