On Tuesday 24 April 2012 05:11:54 Michael Kerrisk (man-pages) wrote: > The > .BR process_vm_readv () > system call transfers data from the remote process to the local process. > The data to be transferred is identified by > .IR remote_iov > and > .IR riovcnt : > .IR remote_iov > is a pointer to an array describing address ranges in the process > .IR pid , maybe add the word "remote" here: ... in the remote process pid, ... > The data is transferred to the locations specified by > .IR local_iov > and > .IR liovcnt : > .IR local_iov > is a pointer to an array describing address ranges in the calling process, calling -> local > The > .BR process_vm_writev () > system call is the converse of > .BR process_vm_readv ()\(emit this renders as: ... process_vm_readv()—it transfers ... were you going to kill off that weird dash, or just add spacing around it ? > Other than the direction of the transfer, the arguments > .IR liovcnt , > .IR local_iov , > .IR liovcnt , > and > .IR remote_iov > have the same meaning as for > .BR process_vm_readv (). that second liovcnt is supposed to be riovcnt > Note, however, that these system calls do not check the memory regions > in the remote process until just before doing the read/write. > Consequently, a partial read/write (see RETURN VALUE) should that RETURN VALUE be bolded ? > may result if one of the > .I remote_iov > elements points to an invalid memory region in the remote process. > No further reads/writes will be attempted beyond that point. > Keep this in mind when attempting to read data of unknown length > (such as C strings that are null-terminated) from a remote process, > by avoiding spanning memory pages (typically 4KiB) in a single remote > .I iovec > element. > (Instead, split the remote read into two > .I remove_iov > elements and have them merge back into a single write array entry. maybe change "array" to "local_iov" -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
