Jeremy Fitzhardinge wrote: > It would be terribly useful to have some way of > lseeking /proc/<pid>/maps to the entry of a particular address. So, if > you want to find the information about a mapping containing address > 0x12345678, it would set the file position to (say) the entry of > 0x12000000-0x20000000. > > I haven't looked at how /proc/<pid>/maps is implemented these days; is > this outright hard, or relatively straightforward? This wouldn't be > very useful if it had to actually generate all the output up to the > desired point, but it would be a boon if it could short-circuit that. I > guess the interactions with normal lseek might be tricky (but perhaps > that could be put off until you actually use lseek, if ever).
We can do lseek to any position with SEEK_CUR or SEEK_SET. That position is byte position, not map number or map address. Changing byte position with lseek generates all the output upto the desired point inside the kernel using seq traverse(). Moreover records are not of fixed lengths. But given the adress, finding the page can be short circuited (find_vma() finds it in O(log n) time). There is no API from user. Changing the semantics of lseek to other than byte position does not look right. > > Alternatively, any other API for finding the properties of page X would > be useful, but this seemed like a nice incremental extension of the > existing interface. Yes, Proc files do not implement ioctl method. I guess we can add this feature as ioctl on /proc/pid/maps file, if everyone agrees that is right. One of the following methods. ioctl (fd, GET_MAP, address, buf) - Does not interfere with lseek or read. Find it and copy it. OR ioctl (fd, SET_FPOS, address) - Changes the file position to the byte position of the map corresponding to address, and next read returns the data from that position. Once the adress is found, this needs generating all the data upto that address similar to lseek. If we convert maps to fixed length records, it would be better, but still needs to find how many records were before this record. Thanks, Prasanna. - 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/
