[Ksummit-2010-discuss] [v2] Remaining BKL users, what to do

Dave Airlie airlied at gmail.com
Mon Oct 18 21:03:17 PDT 2010

>> like I'm sure the intersection of this driver and reality are getting
>> quite limited, but its still a userspace ABI change and needs to be
>> treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
>> old driver/API.
> Thus, you are saying that this will break for people with older user
> apps and have a newer kernel?

There are two drivers here:



The i830 case is the case I care less about since the ABI is only used
by older userspace and i915 provides a replacement.

the i810 case ABI is still in use today by distro userspaces that are
still released, i.e. i810 is still used in F14, Ubuntu 10.10, RHEL6
Beta etc.

I've snipped the rest of the argument on the grounds you are
conflating two cases that aren't the same.

>> Well the thing is doing the work right is a non-trivial task and just
>> dropping support only screws the people using the hardware,
>> it doesn't place any burden on the distro developers to fix it up. If
>> people are really serious about making the BKL go away completely, I
>> think the onus should be on them to fix the drivers not on the users
>> who are using it, like I'm  guessing if this gets broken the bug will
>> end up in Novell or RH bugzilla in a year and nobody will ever see it.
> Well the problem comes down to testing it. I don't know of any developer
> that is removing the BKL that actually owns hardware to test out these
> broken drivers. And for the change not being trivial, means that there's
> no way to do in correctly.

So we can drop i830 using deprecation, however its pointless since the
fix for i810 is the same fix for i830 if we can work out the fix.

Well the way to do it correctly is make it so if the driver is
initialised and we do an SMP transition we warn the users, or we make
BROKEN_ON_SMP into a runtime thing that warns when the driver is
loaded on an SMP system. The intersection of SMP and this hardware is
definitely a very very small number and a lot more workable.


More information about the dri-devel mailing list