Chris McKillop wrote:
Chris, that’s a real JOKE!
Tell me why identical mmap() calls are working with 6.2.0 and not with
6.2.1!!
Because mmap() is a message Armin. Do you even understand how QNX works?
Chris, I’m working with QNX more than 10 years … in the meantime I’m
convienced to know how QNX is working.
Do you know what’s the value of a documented library interface call?
It should work as documented … even when it is a very low level
function of the OS library.
It is the handler for /dev/mem inside of procnto that has changed, not
mmap() itself. This is like saying that because fs-foo fails to allow
files to be open()'d in 6.2.1 that open() is broken in 6.2.1 (fictional
example, there is no fs-foo). It isn’t open() that is broken, it is
fs-foo. Just like with your mmap() example.
Nice examples … but they are off topic. from the user’s point of view
it is completely unimportant what is failing behind the documented
interface!
Do you know what means compatibility between different OS versions??
How do you think malloc() works? It uses mmap(), in fact
(thanks Brian) every single virtual address in every single process is
obtained by using mmap(). So all memory, binaries, shared libs, etc are
using mmap() to function.
But I’m sure … these calls are NOT using MAP_PHYS!
No, but have you looked at what mmap_device_memory() calls?
(can be found in lib/c/qnx/mmap_device_memory.c)
This has nothing to do with your previous statement.
void *mmap_device_memory( void *addr, size_t len, int prot,
int flags, uint64_t physical)
{
return mmap64( addr, len, prot,
(flags & ~MAP_TYPE) | MAP_PHYS|MAP_SHARED,
NOFD, physical);
}
So tell me, if this works how can mmap() be broken?
This question should be answered by QSSL!
This code has not
changed since 1998 when it was changed to use 64bit values.
I cross my fingers that this interface will not be changed in the
future at least.
Just copied from the mmap() doc:
Or share memory with hardware such as video memory on an x86 platform:
/* Map in VGA display memory */
addr = mmap( 0,
65536,
PROT_READ|PROT_WRITE,
MAP_PHYS|MAP_SHARED,
NOFD,
0xa0000 );
Notice the parameter NOFD …
Yes, I notice it. It isn’t opening /dev/mem though is it?
This isn’t the issue here. Your idea was to provide a real file
descriptor instead of NOFD … but you have deleted this statement from
your response.
If mmap() returns a value of addr > NULL and this value creates a memory
violation if you use it … you are trying to tell all of us here that
this isn’t a bug??
No,
No ?
not when it returns MAP_FAILED which is -1.
If have learned that NULL is > -1 … isn’t it??
Like I said, don’t you
check your return values? No where in any of the docs does it say that
it will return NULL/0 on failure.
I have to correct myself … I’m checking for the -1 since I’m using
mmap().
Armin
I am sure that you