Re: proc_lseek backport request

[Greg KH <gregkh@linuxfoundation.org>]

On Mon, Aug 21, 2023 at 08:28:44AM +0200, t.martitz@avm.de wrote:
> >Attempting to keep kernel code outside of the kernel tree is, on
> >purpose, very expensive in time and resources. The very simple way
> >to
> >solve this is to get your drivers merged properly into the mainline
> >kernel tree.
> >
> >Have you submitted your drivers and had them rejected?
> 
> Most drivers affected by the above patch are delivered to us by
> chip vendors that we cannot post publicly without their consent.

As it's all GPLv2 code, you don't need their "consent" to post the code
publicly, in fact, you are obligated to do so :)

> It's
> also not our job to get their crappy code (and it's a lot of that!) to a
> state that meets your quality standards. We can and do ask for mainline
> drivers but our influence is limited.

You can write this into your contract in order to pick their chips.
That's how this was resolved decades ago for scsi and ethernet
chips/drivers, you have more influence here than you might think.

> Also, would driver code for chips that aren't publicly available any useful for you?

Of course it would, it's available for someone, right?

> There is also some in-house code affected but that "drivers" don't usually
> drive hardware but simply provide F!OS-specific proc interfaces (F!OS
> is the name of the firmware that runs on our devices). These are just
> software, often device or vendor specific, and not suitable for the wider
> kernel community. Also we don't have the resources to get our code
> top-notch for potential mainline inclusion (although it's usually better
> than the vendor code we receive).

As stated many times before, by many companies, you will save time and
money if you get your code merged upstream.  If you have time and money
to burn (like nvidia), then sure, keep the code out of the kernel tree,
it's your choice.

> On the positive side, we do realize that mainlining things can be a net win for us
> long term and we have started an internal process that allows us to selectively
> mainline portions of our in-house code, but it's limited by resources and
> therefore a slow process. See [1] for example.
> 
> [1] https://lore.kernel.org/all/20230619071444.14625-1-jnixdorf-oss@avm.de/

That's great!

> >Have you taken advantage of the projects that are willing to take
> >out-of-tree drivers and get them merged upstream properly for free?
> 
> I don't know about any such project. Interesting to hear they exist! Who are they?

The old "driverdevel" mailing list would do this, but that got removed
many years ago when companies stopped needing this.  If you are
interested, email me off-list and we can take it from there.

thanks,

greg k-h