shm_open, shm_unlink, mmap, munmap and close what gives?
Chris Fought
I am attempting to create a device driver for a PCI shared memory device.
The problem I have right now is that I am not sure what to do with memory
that I have mmapped to close both the file descriptor for the shared memory
object and unmap the memory. I mmap memory to the device like this:
fd=shm_open("Physical", O_RDWR, 0777);
......do some stuff here
mem_ptr1=mmap(0,0x400000,prots,flags,fd,scr_reg.Base_Address_Regs[1]);
mem_ptr=mmap(0,0x400000,prots,flags,fd,scr_reg.Base_Address_Regs[2]);
shm_unlink("Physical");
munmap((void*)mem_ptr1,0x400000);
munmap((void*)mem_ptr,0x400000);
I looked at some examples in the QNX Library Reference II manual and I see
that munmap() is never called in the example code for the shm_open()
function. Also I see from the following page on the QNX online knowledge
base:
http://qdn.qnx.com/support/bok/solution.qnx?9417 that I should unmap the
memory mapped by mmap via munmap and close the shared memory file
descriptor. What about shm_unlink though? So my question is what I should
do? I have tried this with the following results:
1st attempt
shm_open
mmaps
close(fd);
shm_unlink ("Physical");
munmaps
This resulted in shm_unlink reporting invalid argument from errno.
2nd attempt
shm_open
mmaps
shm_unlink("Physical");
close(fd);
munmaps
This resulted in shm_unlink reporting invalid argument from errno.
3rd attempt
shm_open
mmaps
close(fd)
munmaps
munmaps works fine? Errno is not set by munmap when doing this (*scratches
head a little*)
4th attempt
shm_open
mmaps
munmaps
close(fd);
munmap works ok like this too, maybe it doesn't matter?
What should I do, could someone please help me!!!
Chris Fought
Mario Charest
"Chris Fought" <cfo...@systran.com> wrote in message
news:PJqy6.234$Mt5....@newsfeed.slurp.net...
> Hi Everyone;
> I am attempting to create a device driver for a PCI shared memory
device.
> The problem I have right now is that I am not sure what to do with memory
> that I have mmapped to close both the file descriptor for the shared
memory
> object and unmap the memory. I mmap memory to the device like this:
>
> fd=shm_open("Physical", O_RDWR, 0777);
> ......do some stuff here
> mem_ptr1=mmap(0,0x400000,prots,flags,fd,scr_reg.Base_Address_Regs[1]);
> mem_ptr=mmap(0,0x400000,prots,flags,fd,scr_reg.Base_Address_Regs[2]);
>
> shm_unlink("Physical");
Yeik, shm_unlink tries to delete the "file" but "Physical" is created by
the OS. shm_unlink is usefull if shm_open was used to CREATE
the share mem file, which is not the case in your example.
> munmap((void*)mem_ptr1,0x400000);
> munmap((void*)mem_ptr,0x400000);
>
> I looked at some examples in the QNX Library Reference II manual and I see
> that munmap() is never called in the example code for the shm_open()
> function. Also I see from the following page on the QNX online knowledge
> base:
> http://qdn.qnx.com/support/bok/solution.qnx?9417 that I should unmap the
> memory mapped by mmap via munmap and close the shared memory file
> descriptor. What about shm_unlink though? So my question is what I should
> do? I have tried this with the following results:
>
> 1st attempt
> shm_open
> mmaps
> close(fd);
> shm_unlink ("Physical");
> munmaps
>
> This resulted in shm_unlink reporting invalid argument from errno.
That makes sense since you are not allow to delete this.
>
> 2nd attempt
> shm_open
> mmaps
> shm_unlink("Physical");
Same probleme here.
> close(fd);
> munmaps
>
> This resulted in shm_unlink reporting invalid argument from errno.
>
> 3rd attempt
> shm_open
> mmaps
> close(fd)
> munmaps
>
> munmaps works fine? Errno is not set by munmap when doing this (*scratches
> head a little*)
>
> 4th attempt
> shm_open
> mmaps
> munmaps
> close(fd);
>
> munmap works ok like this too, maybe it doesn't matter?
>
Actually close and mmaps are to some extend unrelated.
The shm_open is required because mmaps needs a file descriptor.
Actually you could close the file descriptor after the mmaps.
If you are using QNX6 have a look at mmap_device_memory()
Mario Charest
F*#k I hate cross-posting, I just reponded to this for nothing since
somebody else did in another conference, grrrrrrrrrrr
"Mario Charest" <mcha...@deletezinformatic.com> wrote in message
news:2quy6.5842$hV3.1...@weber.videotron.net...