On Sun, 2006-08-06 at 12:48 -0700, Andrew Morton wrote:
> kmap() is a nasty thing. It has theoretical deadlock problems (which used
> to be real ones back in the 2.4 days) and the present implementation uses a
> kernel-wide lock.
>
> We've been gradually and sporadically working to make kmap() go away, so
> please let's not do anything which encourages its use.
>
> kmap_atomic() is much preferred. Can this initiative be recast around
> kmap_atomic()?
Well the API change intercepts both kmap/kunmap and
kmap_atomic/kunmap_atomic; it's designed to be agnostic to the _atomic
bit (I just wrote kmap/kunmap in the Subject line because I was saving
letters). Since it's intended as a flushing API, it has no context
issues, so the parisc implementation is the similar for both (the only
difference being the return value).
However, while kmap exists, it also has to be intercepted for this
approach to work...
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
