accessing non-process-space functions

Nnamdi_Kohn1 · September 9, 2003, 11:35am

Hello,

I have a problem finding a solution to executing a function (or different
functions) that is seated in another process-space than the cause for the
function call. Sharing DATA in different process spaces is done by using QNX
shared memory facilities. But how do I create a shared memory region for
execution of FUNCTIONs?

In detail:

I have built a communication interface driver module that is accessible as a
QNX resource. In normal operation a user-process accesses this driver module
to execute certain driver functions seated inside the driver process space.
The driver module additionally receives interrupts from the communication
interface and performs certain processing… Now I want this driver to
execute USER DEFINED functions as well. That is, the user compiles and
builds his user-application and defines in it functions that are to be
executed when the driver-application receives a certain trigger from the
communication interface (e.g. an interrupt).

With a system that operates without an operating system, this would be no
problem because there are no process-memory restrictions. So every part of
each program could access every memory location and thus start any function
in the global memory space. But with QNX there are memory restrictions so
that in the normal case only process-internal functions can be executed.

Does somebody know how a concept for the execution of non-process functions
could look like?

Regards.

Nnamdi

Mario_Charest1 · September 9, 2003, 12:23pm

“Nnamdi Kohn” <nnamdi.kohn@tu-bs.de> wrote in message
news:bjkd55$6tt$1@inn.qnx.com…

Hello,

I have a problem finding a solution to executing a function (or different
functions) that is seated in another process-space than the cause for the
function call. Sharing DATA in different process spaces is done by using
QNX
shared memory facilities. But how do I create a shared memory region for
execution of FUNCTIONs?

In detail:

I have built a communication interface driver module that is accessible as
a
QNX resource. In normal operation a user-process accesses this driver
module
to execute certain driver functions seated inside the driver process
space.
The driver module additionally receives interrupts from the communication
interface and performs certain processing… Now I want this driver to
execute USER DEFINED functions as well. That is, the user compiles and
builds his user-application and defines in it functions that are to be
executed when the driver-application receives a certain trigger from the
communication interface (e.g. an interrupt).

With a system that operates without an operating system, this would be no
problem because there are no process-memory restrictions.

It’s not a restriction it’s a feature

So every part of
each program could access every memory location and thus start any
function
in the global memory space. But with QNX there are memory restrictions so
that in the normal case only process-internal functions can be executed.

Does somebody know how a concept for the execution of non-process
functions
could look like?

1- The QNX way would be to send a message between the user program and the
driver.
2 - Setup your user program to be a share object (dll) the driver loads and
runs. The user program and driver would then shares code and data. Not
really nice because if user program crashes it can take down the driver.
One example of this is io-net.
3 - Setup shared memory to contains code (very ugly solution IMHO)

Regards.

Nnamdi

Nnamdi_Kohn1 · September 9, 2003, 1:35pm

Hi Mario,

1- The QNX way would be to send a message
between the user program and the driver.

You mean that the driver module sends a message to the user module as soon
as an driver event occures. In this case the user module would have to act
as a server and wait on messages, but it does not. In my application the
user module has to be a client and the driver has to be a server.

2 - Setup your user program to be a share object (dll)
the driver loads and runs. The user program and driver
would then share code and data. Not really nice because
if user program crashes it can take down the driver.

Could not be done because the driver is a permanent ressource and there are
different user modules able to flexibly interact with it. There is an
application programmer interface for the driver that is already included in
the user module.

3 - Setup shared memory to contains code
(very ugly solution IMHO)

This sounds interesting. How can I do that for the user code. I mean, while
seting up shared memory,

you would have to know the amount of memory the code is going to occupy.
you would have to specify at compile, build or run time where the user
function code is to be written in order for the driver module to access it.
I wouldn’t know how to do that.

Isn’t it? Or maybe I could share the user memory space that holds the
functions and jump there from the driver application. Is this possible? Or
could I just set up a user thread that waits for a condition that is shared
between user module and driver module? There the condition would be
evaluated and then the local function could be executed. Yeah, that sounds
good. I will try it.

Thank you.

Nnamdi

Rennie_Allen2 · September 9, 2003, 3:47pm

Nnamdi Kohn wrote:

2 - Setup your user program to be a share object (dll)
the driver loads and runs. The user program and driver
would then share code and data. Not really nice because
if user program crashes it can take down the driver.

Could not be done because the driver is a permanent ressource and there are
different user modules able to flexibly interact with it. There is an
application programmer interface for the driver that is already included in
the user module.

How does this preclude using a dll ? Using io-net I mount and unmount dll’s all the time. The driver is a “permanent” resource, and
the user dlls are ephemeral resources relative to the driver. This sounds exactly like what you are asking for.

Your user app starts, mounts its “user-defined” extensions into the driver, and goes to work. When it leaves, it unmounts its
“user-defined” extensions, and exits.

David_Gibbs1 · September 9, 2003, 5:08pm

Nnamdi Kohn <nnamdi.kohn@tu-bs.de> wrote:

Hello,

I have a problem finding a solution to executing a function (or different
functions) that is seated in another process-space than the cause for the
function call. Sharing DATA in different process spaces is done by using QNX
shared memory facilities. But how do I create a shared memory region for
execution of FUNCTIONs?

The basic way of doing this is to create a shared object, also called
a DLL. They are, almost literally, a shared memory region for execution
of functions.

There is no way for code in one process to directly call normal functions
in the address space of another process.

In detail:

I have built a communication interface driver module that is accessible as a
QNX resource. In normal operation a user-process accesses this driver module
to execute certain driver functions seated inside the driver process space.
The driver module additionally receives interrupts from the communication
interface and performs certain processing… Now I want this driver to
execute USER DEFINED functions as well. That is, the user compiles and
builds his user-application and defines in it functions that are to be
executed when the driver-application receives a certain trigger from the
communication interface (e.g. an interrupt).

The natural way to do this, is for the user to compile and build his
user-defined functions into a shared object (dll).

When the user-application registers with the server, it would send it
a message telling it what shared object to load (done with dlopen()),
and which functions the server is going to call for each trigger
(a table of triggers and symbol names, the server would resolve the
symbol names in the shared object by using dlsym().)

With a system that operates without an operating system, this would be no
problem because there are no process-memory restrictions. So every part of
each program could access every memory location and thus start any function
in the global memory space. But with QNX there are memory restrictions so
that in the normal case only process-internal functions can be executed.

Does somebody know how a concept for the execution of non-process functions
could look like?

Again, that is the simple definition of a shared object/dll – these are
non-process functions that can be dynamically loaded into and used by
a process.

The other possible way of doing this, would be for the user-application
to get notification of events (server would call MsgDeliverEvent()), then
run the code in the application process space. This will give a more
complete seperation of application and server, at the cost of more latency
in the handling of events due to the extra context switch.

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Mario_Charest1 · September 9, 2003, 6:15pm

“Nnamdi Kohn” <nnamdi.kohn@tu-bs.de> wrote in message
news:bjkk5v$bqr$1@inn.qnx.com…

Hi Mario,

1- The QNX way would be to send a message
between the user program and the driver.

You mean that the driver module sends a message to the user module as soon
as an driver event occures. In this case the user module would have to act
as a server and wait on messages, but it does not.

You mean it’s consuming 100% of the CPU? Most of the time process must wait
on something, timer, pulses, socket etc. A separate thread can handle the
message, if you are worried about response time.

In my application the
user module has to be a client and the driver has to be a server.

I don’t think as the direction of the message as the main definition to what
server and client are.

2 - Setup your user program to be a share object (dll)
the driver loads and runs. The user program and driver
would then share code and data. Not really nice because
if user program crashes it can take down the driver.

Could not be done because the driver is a permanent ressource and there
are
different user modules able to flexibly interact with it. There is an
application programmer interface for the driver that is already included
in
the user module.

3 - Setup shared memory to contains code
(very ugly solution IMHO)

This sounds interesting.

No it does not… I think you are having a culture clash and need to think
differently. This is NOT the QNX way at all and might cause you grief in
the long run

Bill_Caroselli1 · September 9, 2003, 6:35pm

Mario Charest postmaster@127.0.0.1 wrote:

MC > “Nnamdi Kohn” <nnamdi.kohn@tu-bs.de> wrote in message

3 - Setup shared memory to contains code
(very ugly solution IMHO)

This sounds interesting.

MC > No it does not… I think you are having a culture clash and need to think
MC > differently. This is NOT the QNX way at all and might cause you grief in
MC > the long run

No one ever accues QNX users of being diplomats!

But Mario is right.

It just doesn’t amke sence to “port” things that are much easier to
redesign using the QNX mechinisms that are there to help you.

Spend a few days learning the QNX IPC (Inter-Process Communication)
techniques and I think you’ll be convinced.

“Toto, I don’t think we’re in MSland any more!”

Rennie_Allen2 · September 12, 2003, 9:09am

Nnamdi Kohn wrote:

could you tell me some more about this possibility (a book or an internet
site,…). You may be right and my knowledge too limited, yet. I’d like to
learn some more about dynamically shared libraries and their development.

Google is your friend; try “shared objects linux” for an overview.

The “magic” for user defined extensions to a driver is to have a message that
you send to the driver that causes it to open and load a dll containing the user
defined extensions. If you write a standard QNX resource manager, there is a
callback already defined for this purpose called “mount”. For instance to
install the “user defined” extension called TCP/IP into the “network driver”
io-net (network driver is quoted since io-net is really just a hook where both
drivers and protocol extensions are hung) you issue the command:

“mount -Tio-net npm-tcpip.so”.

If you had some mythical driver named “foo” you might accomplish a installation
of a user defined extension like so:

“mount -Tfoo user-defined.so”

Nnamdi_Kohn1 · September 12, 2003, 12:25pm

“Bill Caroselli” <qtps@earthlink.net> schrieb im Newsbeitrag
news:bjl6i4$o6v$1@inn.qnx.com…

Mario Charest postmaster@127.0.0.1 wrote:

MC > “Nnamdi Kohn” <> nnamdi.kohn@tu-bs.de> > wrote in message

3 - Setup shared memory to contains code
(very ugly solution IMHO)

This sounds interesting.

MC > No it does not… I think you are having a culture clash and need to
think
MC > differently. This is NOT the QNX way at all and might cause you
grief in
MC > the long run

No one ever accues QNX users of being diplomats!

But Mario is right.

It just doesn’t amke sence to “port” things that are much easier to
redesign using the QNX mechinisms that are there to help you.

Spend a few days learning the QNX IPC (Inter-Process Communication)
techniques and I think you’ll be convinced.

“Toto, I don’t think we’re in MSland any more!”

Thank you. I will spend some days on that.

Are there any tests for determining the operation times (speeds) of the
different IPC techniques? I think there will be some dependencies on
NumberOfWaitingProcesses, ProcessorSpeed, UsedTechnique (Pulse, Signal,
Message, ShMem) and TransferredDataAmount. Are there any of these techniques
already tested in a speed-defining manner?

Nnamdi

Nnamdi_Kohn1 · September 12, 2003, 12:27pm

“Rennie Allen” <rallen@csical.com> schrieb im Newsbeitrag
news:3F5DF612.2010108@csical.com…

Nnamdi Kohn wrote:

2 - Setup your user program to be a share object (dll)
the driver loads and runs. The user program and driver
would then share code and data. Not really nice because
if user program crashes it can take down the driver.

Could not be done because the driver is a permanent ressource and there
are
different user modules able to flexibly interact with it. There is an
application programmer interface for the driver that is already included
in
the user module.

How does this preclude using a dll ? Using io-net I mount and unmount
dll’s all the time. The driver is a “permanent” resource, and
the user dlls are ephemeral resources relative to the driver. This sounds
exactly like what you are asking for.

Your user app starts, mounts its “user-defined” extensions into the
driver, and goes to work. When it leaves, it unmounts its
“user-defined” extensions, and exits.

could you tell me some more about this possibility (a book or an internet
site,…). You may be right and my knowledge too limited, yet. I’d like to
learn some more about dynamically shared libraries and their development.

Nnamdi

Nnamdi_Kohn1 · September 12, 2003, 12:41pm

The other possible way of doing this, would be for the user-application
to get notification of events (server would call MsgDeliverEvent()), then
run the code in the application process space. This will give a more
complete seperation of application and server, at the cost of more latency
in the handling of events due to the extra context switch.

Thanks.

Are there any comparation tests available then for e.g. MsgDeliverEvent()
versus Pulses or other IPC techniques? I’d like to implement the fastest
possible way to handle these signalling and user-function-execution.

Nnamdi

Bill_Caroselli1 · September 12, 2003, 6:26pm

Rennie Allen <rgallen@attbi.com> wrote:
RA > Nnamdi Kohn wrote:

could you tell me some more about this possibility (a book or an internet
site,…). You may be right and my knowledge too limited, yet. I’d like to
learn some more about dynamically shared libraries and their development.

RA > Google is your friend; try “shared objects linux” for an overview.

RA > The “magic” for user defined extensions to a driver is to have a message that
RA > you send to the driver that causes it to open and load a dll containing the user
RA > defined extensions. If you write a standard QNX resource manager, there is a
RA > callback already defined for this purpose called “mount”. For instance to
RA > install the “user defined” extension called TCP/IP into the “network driver”
RA > io-net (network driver is quoted since io-net is really just a hook where both
RA > drivers and protocol extensions are hung) you issue the command:

RA > “mount -Tio-net npm-tcpip.so”.

RA > If you had some mythical driver named “foo” you might accomplish a installation
RA > of a user defined extension like so:

RA > “mount -Tfoo user-defined.so”

Is “foo” simply the name of a currently loaded executabe?
Or is it the name of some registered resource?

Rennie_Allen2 · September 14, 2003, 5:04pm

Bill Caroselli wrote:

RA > “mount -Tfoo user-defined.so”

Is “foo” simply the name of a currently loaded executabe?
Or is it the name of some registered resource?

That example was meant to be illustrative of the underlying process (and how it
is commonly used). The actual method that a client app of a custom driver would
likely use, is to call the mount() api (with the full path to the driver and
name of shared object being passed). The idea was to get the OP pointed in the
right direction.

Rennie