There are actually two issues here.
The first issue is how to implement a generic kernel-only cmpxchg routine.
Obviously, you can implement this with cli+sti because all it requires is a
critical section. You don't want to do that if you can avoid it, because
it will be slow, and the only reason you want to use cmpxchg is for speed.
However, if we want to make a functional cmpxchg routine for kernel-only
use, that's fine.
The other issue is how the DRM_LOCK makes use of cmpxchg. For performance
reasons, the DRM_LOCK is shared between user-space and kernel-space, and
the same locking that is done in the kernel must be done in user space.
This allows a user-space processes to take and release the lock WITHOUT
using an ioctl (the ioctl is only used in cases of contention -- all this
is explained in detail in http://precisioninsight.com/dr/locking.html).
Now, if we don't have a cmpxchg instruction that can be used or emulated
from user-space, we can't do our efficient two-tiered locking. However, we
can force all user-space processes to use the ioctl to take and release the
DRM_LOCK all the time, even when there is no contention. This is a serious
performance hit, so we don't want to do that on modern CPUs, but for the
386, which no one is going to use for direct-rendering anyway, it is a
solution that provides functionality without performance. We don't need to
implement that now, though, since we'll never run on a 386 -- I'm just
noting that there is a possible pathway to a 386 solution in case anyone
ever does want to run the DRI on a 386.
For now, I think the best solution is that:
1) I change the drmP.h code to always compile with cmpxchg. We already
guarantee that the DRI will never run on a 386, but I can also add
code to the device driver's open routine so that it cannot be used
on a 386 -- that will handle the case for all those 386s with PCI
busses :)
2) Those interested implement the generic cmpxchg to work on 386
processors, if there is a need. At this time, I don't think this
work is justified unless someone else needs cmpxchg in the kernel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/