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).
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.
J
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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).
>
I'm fairly certain you can just return that the seek is done, and set
flags for the file descriptor, then on read() have it return the data
you want it to.
> 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.
>
> J
>
> -
> 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/
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB600dhDd4aOud5P8RAlvoAJsFi6ZUMTVhqQBWqZFkv8ubeJEyegCfYhhl
6Gy3TLn/ngSQDugT0CxOpnY=
=rR0f
-----END PGP SIGNATURE-----
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.