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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 EE73EC433ED for ; Thu, 29 Apr 2021 15:38:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B810E6144E for ; Thu, 29 Apr 2021 15:38:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234590AbhD2PjJ (ORCPT ); Thu, 29 Apr 2021 11:39:09 -0400 Received: from jptosegrel01.sonyericsson.com ([124.215.201.71]:1832 "EHLO JPTOSEGREL01.sonyericsson.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233420AbhD2PjH (ORCPT ); Thu, 29 Apr 2021 11:39:07 -0400 Subject: Re: [PATCH 00/13] [RFC] Rust support To: Willy Tarreau , 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 References: <20210414184604.23473-1-ojeda@kernel.org> <20210416161444.GA10484@1wt.eu> <20210416173717.GA10846@1wt.eu> <20210420061613.GA30890@1wt.eu> From: peter enderborg Message-ID: Date: Thu, 29 Apr 2021 17:38:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210420061613.GA30890@1wt.eu> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-GB X-SEG-SpamProfiler-Analysis: v=2.3 cv=DLnxHBFb c=1 sm=1 tr=0 a=9drRLWArJOlETflmpfiyCA==:117 a=IkcTkHD0fZMA:10 a=3YhXtTcJ-WEA:10 a=W69p7wgkjsnNkqErQOcA:9 a=QEXdDO2ut3YA:10 X-SEG-SpamProfiler-Score: 0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/20/21 8:16 AM, Willy Tarreau wrote: > 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". In the parallel universe where I spent most time everyone now need to learn how to make their things to work out-of-tree. And there is not much of business case trying to fix and improve core parts of linux. The turn around have increased a lot and there is no edge doing it. > 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). Things have changed. Once upon a time the community was happy if it could get hardware specs. > Just my two cents, > Willy