a word on regressions
Dave Airlie
airlied at gmail.com
Wed Apr 24 01:40:35 UTC 2019
On Wed, 24 Apr 2019 at 11:13, Dave Airlie <airlied at 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.
More information about the dri-devel
mailing list