Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp3075615pxb; Mon, 19 Apr 2021 23:17:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFQVQbdO+xHSOrOB28rI9Msps+VKAAU+GiO4dH898hWSf6B9mapkEOTOrv/4521X7iqAU3 X-Received: by 2002:a65:4985:: with SMTP id r5mr15283472pgs.65.1618899442196; Mon, 19 Apr 2021 23:17:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618899442; cv=none; d=google.com; s=arc-20160816; b=XOd6WZyIqRxGuIXZskv8ZFbyNckyR2YLbjC7Q/FHeQ2dsEzdydoilzdNfgBuc0vT0J 96rh6mSzt1I1qe2Eccb3UIoTIclFGquhiADipUekSxXPTPXi0+ZzpZ3PDlvPSC4XAN4c 4Bj1h7L9jlonVfVl/oZWwRBvEmR5xZCdsLNuQ+Ar8SB/G0blwcVYXJ/5kFwUDvTkQQaI cKJR8KgILKuPoF0o4xwNaBuNSVBo7AMUW2O09W3uDbE4tMtRDFf4VTxjT2F80enwNSPK aoTuxIgbVl8ISuKj1hOMyOKxBHOT7GVcDAoCnmnJyhfWwAHLQM8XwmHMoemIVvdLVVV0 xXrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=cqfuDm2lmdxPlD0t6O2AciQhgAjGwPRlcSD7YCpHPpA=; b=iaHxQrfP5iqIst5lf+rkYmLt+7HvWub4OBePFK0UYvyW9SDRcizpIWYRIF5PEZLSlJ LNpgZZQI68lMAoGiVRV4H3TrjsdGzJiBPQD0QW4SdrtWjGMmN8XxyL9TCty1pJY4FWRD QSQqgMME/RD6r6lR/RqHPVNDiGXLbiQlHXBC4IIe49HyORF6MGvc/mUGbAuNdxvwnE+1 VNnxiokKH7C4agAi3SpQFhEhs1RPWjVtVzhSbg5q+6aqCjJrV4plhinIWoIRVyX2D/G1 bVYLnJF6BFuD1dNvL5TyuaVJqykZlZJSVtwe5g4r8iseDD3MH3ZJK2NNteMXmJDofMFf kWqQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l5si19464043pff.131.2021.04.19.23.17.08; Mon, 19 Apr 2021 23:17:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229968AbhDTGRC (ORCPT + 99 others); Tue, 20 Apr 2021 02:17:02 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:51902 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229577AbhDTGRA (ORCPT ); Tue, 20 Apr 2021 02:17:00 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 13K6GDgI030948; Tue, 20 Apr 2021 08:16:13 +0200 Date: Tue, 20 Apr 2021 08:16:13 +0200 From: Willy Tarreau To: Greg Kroah-Hartman Cc: Nick Desaulniers , Wedson Almeida Filho , Peter Zijlstra , Miguel Ojeda , Linus Torvalds , rust-for-linux , Linux Kbuild mailing list , Linux Doc Mailing List , linux-kernel , Dmitry Vyukov , Miguel Ojeda Subject: Re: [PATCH 00/13] [RFC] Rust support Message-ID: <20210420061613.GA30890@1wt.eu> References: <20210414184604.23473-1-ojeda@kernel.org> <20210416161444.GA10484@1wt.eu> <20210416173717.GA10846@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 20, 2021 at 07:56:18AM +0200, Greg Kroah-Hartman wrote: > I would LOVE it if some "executives" would see the above presentations, > because then they would maybe actually fund developers to fix bugs and > maintain the kernel code, instead of only allowing them to add new > features. > > Seriously, that's the real problem, that Dmitry's work has exposed, the > lack of people allowed to do this type of bugfixing and maintenance on > company time, for something that the company relies on, is a huge issue. > "executives" feel that they are willing to fund the initial work and > then "throw it over the wall to the community" once it is merged, and > then they can forget about it as "the community" will maintain it for > them for free. And that's a lie, as Dmitry's work shows. That's sadly the eternal situation, and I'm suspecting that software development and maintenance is not identified as a requirement for a large number of hardware vendors, especially on the consumer side where margins are lower. A contractor is paid to develop a driver, *sometimes* to try to mainline it (and the later they engage with the community, the longer it takes in round trips), and once the code finally gets merged, all the initial budget is depleted and no more software work will be done. Worse, we could imagine kicking unmaintained drivers faster off the tree, but that would actually help these unscrupulous vendors by forcing their customers to switch to the new model :-/ And most of them wouldn't care either if their contributions were refused based on their track record of not maintaining their code, since they often see this as a convenience to please their customers and not something they need (after all, relying on a bogus and vulnerable BSP has never prevented from selling a device, quite the opposite). In short, there is a parallel universe where running highly bogus and vulnerable out-of-tree code seems like the norm and where there is no sort of care for what is mainlined as it's possibly just made to look "cool". We also need to recognize that it's expectable that some vendors are not willing to engage on supporting a driver for a decade if they expect their device to last 5 years only, and maybe we should make some rules clear about mainlining drivers and what to expect for users (in which case the end of support would be clear and nobody would be surprised if the driver is removed at the end of its maintenance, barring a switch to a community maintainer). Just my two cents, Willy