a word on regressions

a word on regressions

[Dave Airlie]

I've been looking a bit at 5.0 for a few things recently, and I've
noticed it shipped with a bunch of regressions, that I'm trying to
smash.

udl driver regression due to gem unlocked cleanup
udl driver unload regression due to other unplug changes
i915 + atomic x.org modesetting driver break
i915 eDP faster/stronger/wider patch fallout
virtio-gpu prime removal broke DRI3

Now in some of the cases here a revert has had to be argued for by me,
and in some cases a revert hasn't happened as quickly as I'd like.

But one thing I've seen in a couple of cases is regression nitpicking,
which isn't acceptable to Linus and hence to me either.

if the sequence happens:
kernel A does something
apply patch X
kernel A+X doesn't do the same thing

then patch X is broken and needs to be reverted
- no matter what patch X fixes
- no matter if the fault patch X uncovers is somewhere in userspace or
in magic other lands,
- no matter if patch X revert regresses something patch X fixes.

I do not want to hear excuses that this patch isn't at fault, or it's
the other userspace problem, it's your problem to engineer around
that, wait 5 years, new CONFIG options, detecting the buggy userspace,
whatever, you are engineering something, go engineer it.

For anyone interested I've reverted the i915 atomic fbdev fix, the
virtio-gpu prime removal, i915 team already did the eDP reverts, and I
did two fixes for udl.

Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: a word on regressions

[Dave Airlie]

On Wed, 24 Apr 2019 at 11:13, Dave Airlie <airlied@gmail.com> wrote:
>
> I've been looking a bit at 5.0 for a few things recently, and I've
> noticed it shipped with a bunch of regressions, that I'm trying to
> smash.
>
> udl driver regression due to gem unlocked cleanup
> udl driver unload regression due to other unplug changes
> i915 + atomic x.org modesetting driver break
> i915 eDP faster/stronger/wider patch fallout
> virtio-gpu prime removal broke DRI3

Oh also:
drm: allow render capable master with DRM_AUTH ioctls
which broke radv.

Dave.
>
> Now in some of the cases here a revert has had to be argued for by me,
> and in some cases a revert hasn't happened as quickly as I'd like.
>
> But one thing I've seen in a couple of cases is regression nitpicking,
> which isn't acceptable to Linus and hence to me either.
>
> if the sequence happens:
> kernel A does something
> apply patch X
> kernel A+X doesn't do the same thing
>
> then patch X is broken and needs to be reverted
> - no matter what patch X fixes
> - no matter if the fault patch X uncovers is somewhere in userspace or
> in magic other lands,
> - no matter if patch X revert regresses something patch X fixes.
>
> I do not want to hear excuses that this patch isn't at fault, or it's
> the other userspace problem, it's your problem to engineer around
> that, wait 5 years, new CONFIG options, detecting the buggy userspace,
> whatever, you are engineering something, go engineer it.
>
> For anyone interested I've reverted the i915 atomic fbdev fix, the
> virtio-gpu prime removal, i915 team already did the eDP reverts, and I
> did two fixes for udl.
>
> Dave.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: a word on regressions

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 1578 bytes --]

Dave Airlie <airlied@gmail.com> writes:

> I've been looking a bit at 5.0 for a few things recently, and I've
> noticed it shipped with a bunch of regressions, that I'm trying to
> smash.
>
> udl driver regression due to gem unlocked cleanup
> udl driver unload regression due to other unplug changes
> i915 + atomic x.org modesetting driver break
> i915 eDP faster/stronger/wider patch fallout
> virtio-gpu prime removal broke DRI3
>
> Now in some of the cases here a revert has had to be argued for by me,
> and in some cases a revert hasn't happened as quickly as I'd like.
>
> But one thing I've seen in a couple of cases is regression nitpicking,
> which isn't acceptable to Linus and hence to me either.
>
> if the sequence happens:
> kernel A does something
> apply patch X
> kernel A+X doesn't do the same thing
>
> then patch X is broken and needs to be reverted
> - no matter what patch X fixes
> - no matter if the fault patch X uncovers is somewhere in userspace or
> in magic other lands,
> - no matter if patch X revert regresses something patch X fixes.
>
> I do not want to hear excuses that this patch isn't at fault, or it's
> the other userspace problem, it's your problem to engineer around
> that, wait 5 years, new CONFIG options, detecting the buggy userspace,
> whatever, you are engineering something, go engineer it.
>
> For anyone interested I've reverted the i915 atomic fbdev fix, the
> virtio-gpu prime removal, i915 team already did the eDP reverts, and I
> did two fixes for udl.

Thank you for tracking these and making sure the reverts happen!

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel