From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 635D0C43463 for ; Sat, 19 Sep 2020 16:44:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 14713208DB for ; Sat, 19 Sep 2020 16:44:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pU9HBPbU" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726528AbgISQoC (ORCPT ); Sat, 19 Sep 2020 12:44:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726463AbgISQoB (ORCPT ); Sat, 19 Sep 2020 12:44:01 -0400 Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3521C0613CE; Sat, 19 Sep 2020 09:44:01 -0700 (PDT) Received: by mail-oi1-x244.google.com with SMTP id a3so11310351oib.4; Sat, 19 Sep 2020 09:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cfduvuo2qaLqbrqkySQg+itnGIveDrg6Cvu0oEAcq/k=; b=pU9HBPbUXcukfQfrJjasbEIUXNL/ChjPxwRvkTvdzlQgmVSa10YyaEIw7ZCOTf+H13 /NW1BQrmCMQLifiBnW0BTazPYzpTWmIFpH8KXJ4txuYts1G5o2iQa5wJdnb3I77WfKUE cTWLqAbnz1m8HqqpJt5UfqDFB1OYtMX6Ixw0SXIzbg8yQQh0UfgIQeDY/CEaj9d5xM4V GVmjVOw+jLpTqhoAbEqcn5gUO916XtAX7I5jFfZYm37l+W5yVFeeQH0mU4pO1b5MrjZW 8xIQ9WInrK/ZhDgPOJMpm5d3rMNNj59KA6nPNoIWY8DXioBAHND0dx9+AGGCqN5jQOE7 kyEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cfduvuo2qaLqbrqkySQg+itnGIveDrg6Cvu0oEAcq/k=; b=jSbadOkvJTD5Pzx/G2yUH9/D4bnnya7tuoRsdSnAQ0H4A3ew0SxAETX5JMUoPpnblF youWFMcbwPooZKIr/w1pfqIG3lozsETKq3wDECgSfteiWh2064H9IwkNObK0plU7Z/W8 lVmmwnwzG6+7VoqUNTjctBwsN4vWrBQqWMKgEZ/iNxkvygeWTO7qWgVRZWSa0lgT9Szx U3+EQcG6IF1o68B4i0Q6X/7jYpxUhYu4OV+F89zLIWcBuS46BPgwrrWo/oWDUM+d7rCz Myr+WHRItGKUTqNW0hm7hGSVmWF/A4saQ4IyqfXi4CwaaSN8z3OHs+IbNevSpcGpVyAk iLRQ== X-Gm-Message-State: AOAM530F+nv9GBXaf8cKvzCLS8sV+XJelLHB93e0CAdcx16D6n4AGNhn nf1gYPBtC9UF413t18clYG3KfXqEbhhLQrV5ZdE= X-Google-Smtp-Source: ABdhPJwJqb/AKIJliKN7dAiHbWX51Djs2BGiO2F9MjnRLdzLcAZrD77jiGwWi8q2T31NGa25n//D/HTIw2eycuiNJNA= X-Received: by 2002:a05:6808:a05:: with SMTP id n5mr13138730oij.154.1600533839763; Sat, 19 Sep 2020 09:43:59 -0700 (PDT) MIME-Version: 1.0 References: <20200917171833.GJ8409@ziepe.ca> <0b21db8d-1061-6453-960b-8043951b3bad@amazon.com> <20200918115227.GR869610@unreal> <20200918120340.GT869610@unreal> <20200918121905.GU869610@unreal> <20200919064020.GC439518@kroah.com> <20200919082003.GW869610@unreal> <20200919083012.GA465680@kroah.com> In-Reply-To: <20200919083012.GA465680@kroah.com> From: Oded Gabbay Date: Sat, 19 Sep 2020 19:43:28 +0300 Message-ID: Subject: Re: [PATCH v3 00/14] Adding GAUDI NIC code to habanalabs driver To: Greg Kroah-Hartman Cc: Leon Romanovsky , Gal Pressman , Jason Gunthorpe , Jakub Kicinski , "Linux-Kernel@Vger. Kernel. Org" , netdev@vger.kernel.org, SW_Drivers , "David S. Miller" , Andrew Lunn , Florian Fainelli , linux-rdma@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Sat, Sep 19, 2020 at 11:30 AM 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. > > > > 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. But we don't do that so why am I being forced to support IBverbs ? 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. Thanks, Oded > > totally lost, > > greg k-h