More questions...
More questions that have come up from this persistent memory work:
a) I would *really* appreciate it if someone would send me userspace memory maps for different architectures. I know what the i386 and x86-64 memory maps look like, but I have no clue on the rest.
b) Is there an architecture-independent way to determine if a page fault was due to a read or write operation? On i386 I can look at the %cr2 value in the sigcontext, but I'd prefer to do something less arch-specific...
By the way, just so people don't think I'm talking about some pie-in-the-sky vaporware project, the current code is available at:
ftp://ftp.zytor.com/pub/hpa/objstore-20011015.tar.gz
It basically has full functionality, although I want to do some more optimizations (e.g. using mremap() for realloc()) and other cleanups (e.g. renaming it something better than "objstore") before releasing it officially. The official release version will *not* be binary compatible; you have been warned...
-hpa
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/
Quoted 9 lines
b) Is there an architecture-independent way to determine if a page fault
was due to a read or write operation? On i386 I can look at the %cr2
value in the sigcontext, but I'd prefer to do something less arch-specific...
The last parameter to handle_mm_fault() ...
Kanoj
__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/
Quoted 11 lines · Kanoj Sarcar
Quoted 8 lines
b) Is there an architecture-independent way to determine if a page fault
was due to a read or write operation? On i386 I can look at the %cr2
value in the sigcontext, but I'd prefer to do something less arch-specific...The last parameter to
handle_mm_fault()...
How do I determine it *in userspace*?
-hpa
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/
Quoted 1 line · H. Peter Anvin
How do I determine it *in userspace*?
No portable way. The portable API (siginfo_t) doesn't supply it ATM. In theory it could be put into si_errno, but no current kernel does that. Most architectures will likely gives it to you in some form in the arch specific signal frame however.
-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/
Quoted 10 lines · Andi Kleen
Quoted 2 lines · H. Peter Anvin
How do I determine it *in userspace*?
No portable way. The portable API (
siginfo_t) doesn't supply it ATM. In theory it could be put intosi_errno, but no current kernel does that. Most architectures will likely gives it to you in some form in the arch specific signal frame however.
IWBNI it could be added, assuming it can be done without breaking existing applications (perhaps a flag could be snuck in somewhere.) I can write the code so that if the information is present, it uses it; otherwise the worst that can happen is having to do the two-step NONE -> READ -> READ|WRITE transition, as it currently is.
-hpa
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/
Quoted 6 lines · H. Peter Anvin
IWBNI it could be added, assuming it can be done without breaking existing applications (perhaps a flag could be snuck in somewhere.) I can write the code so that if the information is present, it uses it; otherwise the worst that can happen is having to do the two-step NONE -> READ -> READ|WRITE transition, as it currently is.
At least on linux si_errno on signals should be always 0. I doubt anything depends on that. I don't know if that is true on other operating systems however. Single Unix has nothing to say about it as far as I can see.
You don't need a flag. Just use it when it is != 0.
-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/
Quoted 9 lines · Andi Kleen
Quoted 6 lines · H. Peter Anvin
IWBNI it could be added, assuming it can be done without breaking existing applications (perhaps a flag could be snuck in somewhere.) I can write the code so that if the information is present, it uses it; otherwise the worst that can happen is having to do the two-step NONE -> READ -> READ|WRITE transition, as it currently is.
Quoted 6 lines
At least on linux
si_errnoon signals should be always 0. I doubt anything depends on that. I don't know if that is true on other operating systems however. Single Unix has nothing to say about it as far as I can see.You don't need a flag. Just use it when it is != 0.
That's a flag as far as I'm concerned... I can do an #ifdef __linux__ and test the value of this field.
-hpa
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/