How to return a pointer from resource managers io_read ?

I’m writing a resource manager for a framegrabber board and have problems
with returning a picture to the client.
In the endless while-loop of the main-function of my resource manager, i
read from a dma-buffer, which contains the actual picture :

Code:
bitmap=dmabuffer+(readyBuffer->start);

bitmap is an unsigned char pointer.

In the io_read - function, i try to return the bitmap to the client :
Code:
// write data to the client
if (nbytes) {

retVal.width = width;
retVal.height = height;
retVal.bpp = bpp;
retVal.bitmap=bitmap;

MsgReply(ctp->rcvid, nbytes, &retVal + off, nbytes);
// Settup POSIX start atime data
ocb->attr->flags |= IOFUNC_ATTR_ATIME | IOFUNC_ATTR_DIRTY_TIME;
// advance the lseek index vy the number of bytes read if not
_IO_XTYPE_OFFSET
if (xtype == _IO_XTYPE_NONE) {
ocb->offset += nbytes;
}
// If we have returned all Data reset offset to 0
if ( nbytes >= sizeof(picCtrlStruct) ) {
ocb->offset = 0;
}
} else {
MsgReply(ctp->rcvid,EOK,NULL,0);
}
return (_RESMGR_NOREPLY);
} // io_read



Where retVal is of the following struct :
Code:
typedef struct {
unsigned char * bitmap; /*!< das Bild /
int height; /
!< Hoehe des Bildes /
int width; /
!< Breite des Bildes */
int bpp;
} picCtrlStruct;


My problem is, that the values of height, width and bpp are returned
correctly, but bitmap doesn’t points to the picture. How can i return the
picture ?

I hope someone can help me,

Cheers

“Tobias Fetzer” <tobiasfetzer@gmx.de> wrote in message
news:co19e7$di1$1@inn.qnx.com

I’m writing a resource manager for a framegrabber board and have problems
with returning a picture to the client.
In the endless while-loop of the main-function of my resource manager, i
read from a dma-buffer, which contains the actual picture :

Code:
bitmap=dmabuffer+(readyBuffer->start);

bitmap is an unsigned char pointer.

In the io_read - function, i try to return the bitmap to the client :
Code:
// write data to the client
if (nbytes) {

retVal.width = width;
retVal.height = height;
retVal.bpp = bpp;
retVal.bitmap=bitmap;

MsgReply(ctp->rcvid, nbytes, &retVal + off, nbytes);
// Settup POSIX start atime data
ocb->attr->flags |= IOFUNC_ATTR_ATIME |
IOFUNC_ATTR_DIRTY_TIME;
// advance the lseek index vy the number of bytes read if not
_IO_XTYPE_OFFSET
if (xtype == _IO_XTYPE_NONE) {
ocb->offset += nbytes;
}
// If we have returned all Data reset offset to 0
if ( nbytes >= sizeof(picCtrlStruct) ) {
ocb->offset = 0;
}
} else {
MsgReply(ctp->rcvid,EOK,NULL,0);
}
return (_RESMGR_NOREPLY);
} // io_read



Where retVal is of the following struct :
Code:
typedef struct {
unsigned char * bitmap; /*!< das Bild /
int height; /
!< Hoehe des Bildes /
int width; /
!< Breite des Bildes */
int bpp;
} picCtrlStruct;


My problem is, that the values of height, width and bpp are returned
correctly, but bitmap doesn’t points to the picture. How can i return the
picture ?

Because of virtual addressing pointers cannot be share across processes.

The really nice solution would be for resource manager to support mmap call,
just like linux/unix drivers can do but that is not available in QNX6. Well
apparently it is possible through black magic but that information is not
available.

Solution #1, use IOV structures to return the bitmap as well as the control
structure. The huge amount of data transfer will take a toll on the CPU
though and depending on CPU could make any can of real-time image processing
impossible. This does present the advantage of working over network.

Solution #2, have the client setup a DMA memory region. Send the server the
physical address of the buffer and have the hardware dump data right into
it. Best is to do this only once when the client start. The bitmap field
of the structre could specify the offset in the memory so you could have
multiple images in the DMA memory.

Solution #3, same as #2, the server setup the DMA memory. Add an IOCTL to
let client get the physical address of the memory and map to it. Only do the
memory mapping in the client once.

Solution #4, have the bitmap in your control structure be a physical address
and let the client map/unmap the memory every on every read. Not nice since
mmap/unmap is somewhat costly.

I hope someone can help me,

Cheers

I’ve written a FireWire camera driver for QNX, and
on a 1.5GHz x86 machine, just getting 640x480 images from the
camera through a resource manager uses under 10%
of the CPU.

QNX is good at copying. Don’t try to make holes in
the memory protection because you think copying is
expensive.

But do big copies; send a whole frame in a single
read.

John Nagle
Team Overbot

Mario Charest wrote:

“Tobias Fetzer” <> tobiasfetzer@gmx.de> > wrote in message
news:co19e7$di1$> 1@inn.qnx.com> …

I’m writing a resource manager for a framegrabber board and have problems
with returning a picture to the client.
In the endless while-loop of the main-function of my resource manager, i
read from a dma-buffer, which contains the actual picture :

Code:
bitmap=dmabuffer+(readyBuffer->start);

bitmap is an unsigned char pointer.

In the io_read - function, i try to return the bitmap to the client :
Code:
// write data to the client
if (nbytes) {

retVal.width = width;
retVal.height = height;
retVal.bpp = bpp;
retVal.bitmap=bitmap;

MsgReply(ctp->rcvid, nbytes, &retVal + off, nbytes);
// Settup POSIX start atime data
ocb->attr->flags |= IOFUNC_ATTR_ATIME |
IOFUNC_ATTR_DIRTY_TIME;
// advance the lseek index vy the number of bytes read if not
_IO_XTYPE_OFFSET
if (xtype == _IO_XTYPE_NONE) {
ocb->offset += nbytes;
}
// If we have returned all Data reset offset to 0
if ( nbytes >= sizeof(picCtrlStruct) ) {
ocb->offset = 0;
}
} else {
MsgReply(ctp->rcvid,EOK,NULL,0);
}
return (_RESMGR_NOREPLY);
} // io_read



Where retVal is of the following struct :
Code:
typedef struct {
unsigned char * bitmap; /*!< das Bild /
int height; /
!< Hoehe des Bildes /
int width; /
!< Breite des Bildes */
int bpp;
} picCtrlStruct;


My problem is, that the values of height, width and bpp are returned
correctly, but bitmap doesn’t points to the picture. How can i return the
picture ?


Because of virtual addressing pointers cannot be share across processes.

The really nice solution would be for resource manager to support mmap call,
just like linux/unix drivers can do but that is not available in QNX6. Well
apparently it is possible through black magic but that information is not
available.

Solution #1, use IOV structures to return the bitmap as well as the control
structure. The huge amount of data transfer will take a toll on the CPU
though and depending on CPU could make any can of real-time image processing
impossible. This does present the advantage of working over network.

Solution #2, have the client setup a DMA memory region. Send the server the
physical address of the buffer and have the hardware dump data right into
it. Best is to do this only once when the client start. The bitmap field
of the structre could specify the offset in the memory so you could have
multiple images in the DMA memory.

Solution #3, same as #2, the server setup the DMA memory. Add an IOCTL to
let client get the physical address of the memory and map to it. Only do the
memory mapping in the client once.

Solution #4, have the bitmap in your control structure be a physical address
and let the client map/unmap the memory every on every read. Not nice since
mmap/unmap is somewhat costly.


I hope someone can help me,

Cheers

\

“John Nagle” <nagle@downside.com> wrote in message
news:co2isn$fgj$1@inn.qnx.com

I’ve written a FireWire camera driver for QNX, and
on a 1.5GHz x86 machine, just getting 640x480 images from the
camera through a resource manager uses under 10%
of the CPU.

QNX is good at copying. Don’t try to make holes in
the memory protection because you think copying is
expensive.

Yes QNX is good but it can still be expensive, 640x480x1 (8 bits) * 30fps
gives 27Mzh a seconds of memory bandwidth (9Mzh to read, 9Mzh to write and
another 9 Meg for the DMA) That’s indeed not much, but system I’m working
on uses 6 camera, to that’s 166Mzh of memory bandwith, of which 126Mzh is
moved by the CPU.


When the system was originaly designed it was using 2 cameras, using message
passing would have work, but with 6 cameras it would have colapse. Using
share mmapping saved the day. Just two months ago we moved to 120Hz
progressive scan camera which quadruple the amount of data (we can’t only
use 4 cameras because of PCI bandwidth issue) and the same architecture was
used.

So it’s about what you need now and what you could need tomorrow.

What’s sad is QNX6 resource manage frame work not supporting mmap. That
forces the client to map physical memory and run as root which does increase
the risk of problem. Otherwise the client could map the memory through the
server eleminating the “holes” in the memory protection.


But do big copies; send a whole frame in a single
read.

John Nagle
Team Overbot

Mario Charest wrote:

“Tobias Fetzer” <> tobiasfetzer@gmx.de> > wrote in message
news:co19e7$di1$> 1@inn.qnx.com> …

I’m writing a resource manager for a framegrabber board and have problems
with returning a picture to the client.
In the endless while-loop of the main-function of my resource manager, i
read from a dma-buffer, which contains the actual picture :

Code:
bitmap=dmabuffer+(readyBuffer->start);

bitmap is an unsigned char pointer.

In the io_read - function, i try to return the bitmap to the client :
Code:
// write data to the client
if (nbytes) {

retVal.width = width;
retVal.height = height;
retVal.bpp = bpp;
retVal.bitmap=bitmap;

MsgReply(ctp->rcvid, nbytes, &retVal + off, nbytes);
// Settup POSIX start atime data
ocb->attr->flags |= IOFUNC_ATTR_ATIME |
IOFUNC_ATTR_DIRTY_TIME;
// advance the lseek index vy the number of bytes read if not
_IO_XTYPE_OFFSET
if (xtype == _IO_XTYPE_NONE) {
ocb->offset += nbytes;
}
// If we have returned all Data reset offset to 0
if ( nbytes >= sizeof(picCtrlStruct) ) {
ocb->offset = 0;
}
} else {
MsgReply(ctp->rcvid,EOK,NULL,0);
}
return (_RESMGR_NOREPLY);
} // io_read



Where retVal is of the following struct :
Code:
typedef struct {
unsigned char * bitmap; /*!< das Bild /
int height; /
!< Hoehe des Bildes /
int width; /
!< Breite des Bildes */
int bpp;
} picCtrlStruct;


My problem is, that the values of height, width and bpp are returned
correctly, but bitmap doesn’t points to the picture. How can i return the
picture ?


Because of virtual addressing pointers cannot be share across processes.

The really nice solution would be for resource manager to support mmap
call, just like linux/unix drivers can do but that is not available in
QNX6. Well apparently it is possible through black magic but that
information is not available.

Solution #1, use IOV structures to return the bitmap as well as the
control structure. The huge amount of data transfer will take a toll on
the CPU though and depending on CPU could make any can of real-time image
processing impossible. This does present the advantage of working over
network.

Solution #2, have the client setup a DMA memory region. Send the server
the physical address of the buffer and have the hardware dump data right
into it. Best is to do this only once when the client start. The bitmap
field of the structre could specify the offset in the memory so you could
have multiple images in the DMA memory.

Solution #3, same as #2, the server setup the DMA memory. Add an IOCTL
to let client get the physical address of the memory and map to it. Only
do the memory mapping in the client once.

Solution #4, have the bitmap in your control structure be a physical
address and let the client map/unmap the memory every on every read. Not
nice since mmap/unmap is somewhat costly.


I hope someone can help me,

Cheers
\

Mario Charest <nowheretobefound@8thdimension.com> wrote:

What’s sad is QNX6 resource manage frame work not supporting mmap. That
forces the client to map physical memory and run as root which does increase
the risk of problem. Otherwise the client could map the memory through the
server eleminating the “holes” in the memory protection.

In the server:

o create a shared memory object with shm_open()
o make the shared memory object overlay the physical memory using
shm_ctl() with SHMCTL_PHYS
o change the ownership of the shared memory object to the clients uid.
o pass the name of the shared memory object to the client.

But do big copies; send a whole frame in a single
read.

John Nagle
Team Overbot

Mario Charest wrote:

“Tobias Fetzer” <> tobiasfetzer@gmx.de> > wrote in message
news:co19e7$di1$> 1@inn.qnx.com> …

I’m writing a resource manager for a framegrabber board and have problems
with returning a picture to the client.
In the endless while-loop of the main-function of my resource manager, i
read from a dma-buffer, which contains the actual picture :

Code:
bitmap=dmabuffer+(readyBuffer->start);

bitmap is an unsigned char pointer.

In the io_read - function, i try to return the bitmap to the client :
Code:
// write data to the client
if (nbytes) {

retVal.width = width;
retVal.height = height;
retVal.bpp = bpp;
retVal.bitmap=bitmap;

MsgReply(ctp->rcvid, nbytes, &retVal + off, nbytes);
// Settup POSIX start atime data
ocb->attr->flags |= IOFUNC_ATTR_ATIME |
IOFUNC_ATTR_DIRTY_TIME;
// advance the lseek index vy the number of bytes read if not
_IO_XTYPE_OFFSET
if (xtype == _IO_XTYPE_NONE) {
ocb->offset += nbytes;
}
// If we have returned all Data reset offset to 0
if ( nbytes >= sizeof(picCtrlStruct) ) {
ocb->offset = 0;
}
} else {
MsgReply(ctp->rcvid,EOK,NULL,0);
}
return (_RESMGR_NOREPLY);
} // io_read



Where retVal is of the following struct :
Code:
typedef struct {
unsigned char * bitmap; /*!< das Bild /
int height; /
!< Hoehe des Bildes /
int width; /
!< Breite des Bildes */
int bpp;
} picCtrlStruct;


My problem is, that the values of height, width and bpp are returned
correctly, but bitmap doesn’t points to the picture. How can i return the
picture ?


Because of virtual addressing pointers cannot be share across processes.

The really nice solution would be for resource manager to support mmap
call, just like linux/unix drivers can do but that is not available in
QNX6. Well apparently it is possible through black magic but that
information is not available.

Solution #1, use IOV structures to return the bitmap as well as the
control structure. The huge amount of data transfer will take a toll on
the CPU though and depending on CPU could make any can of real-time image
processing impossible. This does present the advantage of working over
network.

Solution #2, have the client setup a DMA memory region. Send the server
the physical address of the buffer and have the hardware dump data right
into it. Best is to do this only once when the client start. The bitmap
field of the structre could specify the offset in the memory so you could
have multiple images in the DMA memory.

Solution #3, same as #2, the server setup the DMA memory. Add an IOCTL
to let client get the physical address of the memory and map to it. Only
do the memory mapping in the client once.

Solution #4, have the bitmap in your control structure be a physical
address and let the client map/unmap the memory every on every read. Not
nice since mmap/unmap is somewhat costly.


I hope someone can help me,

Cheers
\

“David Donohoe” <ddonohoe@bulbous.eurospot.com> wrote in message
news:co39v1$1ur$1@inn.qnx.com

Mario Charest <> nowheretobefound@8thdimension.com> > wrote:

What’s sad is QNX6 resource manage frame work not supporting mmap.
That
forces the client to map physical memory and run as root which does
increase
the risk of problem. Otherwise the client could map the memory through
the
server eleminating the “holes” in the memory protection.

In the server:

o create a shared memory object with shm_open()
o make the shared memory object overlay the physical memory using
shm_ctl() with SHMCTL_PHYS
o change the ownership of the shared memory object to the clients uid.
o pass the name of the shared memory object to the client.

Interesting :wink:

But do big copies; send a whole frame in a single
read.

John Nagle
Team Overbot

Mario Charest wrote:

“Tobias Fetzer” <> tobiasfetzer@gmx.de> > wrote in message
news:co19e7$di1$> 1@inn.qnx.com> …

I’m writing a resource manager for a framegrabber board and have
problems
with returning a picture to the client.
In the endless while-loop of the main-function of my resource manager,
i
read from a dma-buffer, which contains the actual picture :

Code:
bitmap=dmabuffer+(readyBuffer->start);

bitmap is an unsigned char pointer.

In the io_read - function, i try to return the bitmap to the client :
Code:
// write data to the client
if (nbytes) {

retVal.width = width;
retVal.height = height;
retVal.bpp = bpp;
retVal.bitmap=bitmap;

MsgReply(ctp->rcvid, nbytes, &retVal + off, nbytes);
// Settup POSIX start atime data
ocb->attr->flags |= IOFUNC_ATTR_ATIME |
IOFUNC_ATTR_DIRTY_TIME;
// advance the lseek index vy the number of bytes read if
not
_IO_XTYPE_OFFSET
if (xtype == _IO_XTYPE_NONE) {
ocb->offset += nbytes;
}
// If we have returned all Data reset offset to 0
if ( nbytes >= sizeof(picCtrlStruct) ) {
ocb->offset = 0;
}
} else {
MsgReply(ctp->rcvid,EOK,NULL,0);
}
return (_RESMGR_NOREPLY);
} // io_read



Where retVal is of the following struct :
Code:
typedef struct {
unsigned char * bitmap; /*!< das Bild /
int height; /
!< Hoehe des Bildes /
int width; /
!< Breite des Bildes */
int bpp;
} picCtrlStruct;


My problem is, that the values of height, width and bpp are returned
correctly, but bitmap doesn’t points to the picture. How can i return
the
picture ?


Because of virtual addressing pointers cannot be share across
processes.

The really nice solution would be for resource manager to support mmap
call, just like linux/unix drivers can do but that is not available in
QNX6. Well apparently it is possible through black magic but that
information is not available.

Solution #1, use IOV structures to return the bitmap as well as the
control structure. The huge amount of data transfer will take a toll
on
the CPU though and depending on CPU could make any can of real-time
image
processing impossible. This does present the advantage of working over
network.

Solution #2, have the client setup a DMA memory region. Send the
server
the physical address of the buffer and have the hardware dump data
right
into it. Best is to do this only once when the client start. The
bitmap
field of the structre could specify the offset in the memory so you
could
have multiple images in the DMA memory.

Solution #3, same as #2, the server setup the DMA memory. Add an IOCTL
to let client get the physical address of the memory and map to it.
Only
do the memory mapping in the client once.

Solution #4, have the bitmap in your control structure be a physical
address and let the client map/unmap the memory every on every read.
Not
nice since mmap/unmap is somewhat costly.


I hope someone can help me,

Cheers

\