On Sat, Sep 19, 2020 at 10:30:12AM +0200, Greg Kroah-Hartman wrote: > On Sat, Sep 19, 2020 at 11:20:03AM +0300, Leon Romanovsky wrote: > > On Sat, Sep 19, 2020 at 08:40:20AM +0200, Greg Kroah-Hartman wrote: > > > On Fri, Sep 18, 2020 at 03:19:05PM +0300, Leon Romanovsky wrote: > > > > > So we do have an open-source library called hl-thunk, which uses our > > > > > driver and indeed that was part of the requirement. > > > > > It is similar to libdrm. > > > > > Here is the link: > > > > > https://github.com/HabanaAI/hl-thunk > > > > > > > > Are you kidding? > > > > > > > > This is mirror of some internal repository that looks like dumpster > > > > with ChangeId, internal bug tracker numbers, not part of major OS > > > > distributions. > > > > > > > > It is not open-source library and shows very clear why you chose > > > > to upstream your driver through driver/misc/ tree. > > > > > > It is an open source library, as per the license and the code > > > availability. What more is expected here? > > > > So can I fork iproute2, add bunch of new custom netlink UAPIs and expect > > Dave to merge it after I throw it on github? > > Don't be silly, that's not the case here at all and you know that. It was far-fetched example. > > > > No distro has to pick it up, that's not a requirement for kernel code, > > > we have many kernel helper programs that are not in distros. Heck, udev > > > took a long time to get into distros, does that mean the kernel side of > > > that interface should never have been merged? > > > > > > I don't understand your complaint here, it's not our place to judge the > > > code quality of userspace libraries, otherwise we would never get any > > > real-work done :) > > > > My main complaint is that you can't imagine merging code into large > > subsystems (netdev, RDMA, DRM? e.t.c) without being civil open-source > > citizen. It means use of existing user-space libraries/tools and/or > > providing new ones that will be usable for everyone. > > Agreed. > > > In this case, we have some custom char device with library that is not > > usable for anyone else and this is why drivers/misc/ is right place. > > Also agreed. > > > While we are talking about real-work, it is our benefit to push companies > > to make investment into ecosystem and not letting them to find an excuse > > for not doing it. > > So why are you complaining about a stand-alone driver that does not have > any shared subsystems's userspace code to control that driver? I didn't, everything started when I explained to Gal why RDMA subsystem requires rdma-core counterpart for any UAPI code. https://lore.kernel.org/linux-rdma/CAFCwf12B4vCCwmfA7+VTUYUgJ9EHAtvg6F0bMYnsSCUBST+aWA@xxxxxxxxxxxxxx/T/#m17d52d61adadf54c12bfecf1af5db40f5d829ac3 And expressed my view on the quality of the library that was presented as open-source example. https://lore.kernel.org/linux-rdma/CAFCwf12B4vCCwmfA7+VTUYUgJ9EHAtvg6F0bMYnsSCUBST+aWA@xxxxxxxxxxxxxx/T/#m9059c5a9405ba932d9ffb731195a43b27443d265 > > Yes, when integrating into other subsystems (i.e. networking and rdma), > they should use those common subsystems interfaces, no one is arguing > that at all. > > totally lost, And here comes my request to do it right https://lore.kernel.org/linux-rdma/CAFCwf12B4vCCwmfA7+VTUYUgJ9EHAtvg6F0bMYnsSCUBST+aWA@xxxxxxxxxxxxxx/T/#ma1fa6fe63666f630674eb668f1c00e6a672db85b All that I asked from Oded is to do UAPI/libraries right, while all the responses can be summarized to one sentence - "it is too hard, we don't want to do it." Thanks > > greg k-h
