Are constant for the moment.
> therefore the userspace mappings still exist for that process. (How am I
> doing?) This means that the copy-from-user() and copy-to-user() can just be
> simple copies.
No they have to consider the processor type, check the source/dest and allow
for the possibility of faults.
Roughly speaking it looks like this (although some of this vanishes for non
386 builds)
check user address and user address+size are in user space, and that
they don't wrap
if the cpu doesnt has working write protect
ensure the faults will be caught/cleaned up [compile time]
copy the data
else
walk the VMA tree to ascertain the addresses are all mapped
copy on write any pages needed
copy the data
fi
Except when you feed it junk, it becomes a straight copy on any decent CPU.
> But I'm still confused by the virt-to-phys macro. I would have thought if I
> want to find the physical address of a user space buffer I would have to go
> through the page table to fins out where is physical page is, not just mask
> off some bits.
You don't want to find the physical address of a user space buffer. For
one thing the answer you get back may cease to apply at an arbitary point in
the future. Secondly you must deal with copy-on-write. The list of problems
continues from there onwards.
Stephen Tweedie is doing code to do this cleanly which will probably by for
the 2.3.x kernel tree. Until then either map kernel space into the user process
as your DMA buffers (see the bttv mmap() operation or the sound drivers), or
don't play with fire
-
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/