More questions...

More questions...

[H. Peter Anvin]

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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: More questions...

[Kanoj Sarcar]

>
> 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: More questions...

[H. Peter Anvin]

Kanoj Sarcar wrote:

> 
>>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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: More questions...

[Andi Kleen]

On Mon, Oct 15, 2001 at 03:02:30PM -0700, H. Peter Anvin wrote:
> 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: More questions...

[H. Peter Anvin]

Andi Kleen wrote:

> On Mon, Oct 15, 2001 at 03:02:30PM -0700, H. Peter Anvin wrote:
>
>>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.
>


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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: More questions...

[Andi Kleen]

On Mon, Oct 15, 2001 at 03:11:44PM -0700, H. Peter Anvin wrote:
>
> 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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/

Re: More questions...

[H. Peter Anvin]

Andi Kleen wrote:

> On Mon, Oct 15, 2001 at 03:11:44PM -0700, H. Peter Anvin wrote:
>
>>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.
>


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 majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/