Message-ID: <e3c591db-a272-5048-7396-3e934b071aab@sony.com>
Date:   Thu, 29 Apr 2021 17:38:14 +0200
From:   peter enderborg <peter.enderborg@...y.com>
To:     Willy Tarreau <w@....eu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Nick Desaulniers <ndesaulniers@...gle.com>,
        Wedson Almeida Filho <wedsonaf@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Miguel Ojeda <ojeda@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Subject: Re: [PATCH 00/13] [RFC] Rust support

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

Powered by blists - more mailing lists