Re: [MAINTAINER SUMMIT] User-space requirements for accelerator drivers

[Geert Uytterhoeven <geert@linux-m68k.org>]

Hi Jani,

On Tue, Sep 14, 2021 at 5:00 PM Jani Nikula <jani.nikula@intel.com> wrote:
> On Tue, 14 Sep 2021, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Sep 14, 2021 at 4:40 PM Jani Nikula <jani.nikula@intel.com> wrote:
> >> On Fri, 10 Sep 2021, Josh Triplett <josh@joshtriplett.org> wrote:
> >> > On Fri, Sep 10, 2021 at 03:00:58PM -0600, Jonathan Corbet wrote:
> >> >>  - What constitutes an acceptable user-space implementation in cases
> >> >>    where these restrictions apply?
> >> >
> >> > This seems like it'll always be a fuzzy line. The main issue: it's OK if
> >> > there are both open and proprietary users, but it's not OK if the only
> >> > open implementation is an outdated or token project that nobody actually
> >> > uses, that exists and is maintained solely for the purposes of placating
> >> > the kernel requirement. There's no easy way to define that line, other
> >> > than "we'll know it when we see it".
> >>
> >> One aspect of it should be easy enough: If you have an issue with your
> >> proprietary stack, but you can't reproduce it with the open stack, you
> >> won't get your fix in the kernel.
> >
> > Which basically boils down to the old mantra: before fixing a bug,
> > first add a new test case to trigger the bug.
>
> Oh, but then the question becomes, is it enough to add a reproducer,
> simplified from your proprietary stack, in your test asset, and then fix
> the kernel issue? Even if it's not a problem in your open stack at all?

I was thinking test ~ open stack.
I.e. enhance the open stack to reproduce the issue.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds