On Sat, Sep 19, 2020 at 07:43:28PM +0300, Oded Gabbay wrote: > On Sat, Sep 19, 2020 at 11:30 AM Greg Kroah-Hartman > <gregkh@xxxxxxxxxxxxxxxxxxx> 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. > > > > > > 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? > > > > 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. > Hi Greg, > It's probably heresy, but why do I need to integrate into the RDMA subsystem ? > I understand your reasoning about networking (Ethernet) as the driver > connects to the kernel networking stack (netdev), but with RDMA the > driver doesn't use or connect to anything in that stack. If I were to > support IBverbs and declare that I support it, then of course I would > need to integrate to the RDMA subsystem and add my backend to > rdma-core. IBverbs are horrid and I would not wish them on anyone. Seriously. > But we don't do that so why am I being forced to support IBverbs ? You shouldn't. > Forcing GAUDI to use the RDMA stack and IBverbs is like swatting flies > with a sledgehammer. > I do hope that in future devices we will support it natively and of > course then we will integrate as requested, but for GAUDI it is just a > huge overkill IMHO. I think the general rdma apis are the key here, not the userspace api. Note, I do not know exactly what they are, but no, IBverbs are not ok. Ick. greg k-h
