name_open vs. open ... what the problem ?

Hi,

Just a dumb question …

// attach point created by name_attach …

// get a fd for MsgSend … ATTACH_POINT== ‘myname’
if ((fd_a = name_open(ATTACH_POINT, 0)) == -1) {
return EXIT_FAILURE;
}

MsgSend(fd_a, … ) works.

// fd by a standard open …
if ((fd_b = open("/dev/name/local/myname", O_RDWR)) == -1) {
return EXIT_FAILURE;
}

MsgSend(fd_b, … ) doesn’t work :frowning:

What’s different with fd_a and fd_b ???

Regards

Armin

The stuff /dev/name is actually owned by proc and so the symantics are
going to be different then a straight open. Use the source Armin - it
is all in libc and on cvs.qnx.com.

chris


Armin <a-steinhoff@web_.de> wrote:

Hi,

Just a dumb question …

// attach point created by name_attach …

// get a fd for MsgSend … ATTACH_POINT== ‘myname’
if ((fd_a = name_open(ATTACH_POINT, 0)) == -1) {
return EXIT_FAILURE;
}

MsgSend(fd_a, … ) works.

// fd by a standard open …
if ((fd_b = open("/dev/name/local/myname", O_RDWR)) == -1) {
return EXIT_FAILURE;
}

MsgSend(fd_b, … ) doesn’t work > :frowning:

What’s different with fd_a and fd_b ???

Regards

Armin
\


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Chris McKillop wrote:

The stuff /dev/name is actually owned by proc and so the symantics are
going to be different then a straight open. Use the source Armin - it
is all in libc and on cvs.qnx.com.

Did it now … the problem seems to be the ‘open’ call.

Comes ‘open’ only back with a connection ID if the path is ‘/dev/xyz’
… is the this
the underlaying semantic ??

It is better to use always ‘name_open’ to setup a connection to
arbitrary designed resource managers??

Regards

Armin

PS: is there a downloadable tar ball of the CVS ??

chris

Armin <a-steinhoff@web_.de> wrote:

Hi,

Just a dumb question …

// attach point created by name_attach …

// get a fd for MsgSend … ATTACH_POINT== ‘myname’
if ((fd_a = name_open(ATTACH_POINT, 0)) == -1) {
return EXIT_FAILURE;
}

MsgSend(fd_a, … ) works.

// fd by a standard open …
if ((fd_b = open("/dev/name/local/myname", O_RDWR)) == -1) {
return EXIT_FAILURE;
}

MsgSend(fd_b, … ) doesn’t work > :frowning:

What’s different with fd_a and fd_b ???

Regards

Armin



\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Armin Steinhoff wrote:

Chris McKillop wrote:

The stuff /dev/name is actually owned by proc and so the symantics are
going to be different then a straight open. Use the source Armin - it
is all in libc and on cvs.qnx.com.

Did it now … the problem seems to be the ‘open’ call.

Comes ‘open’ only back with a connection ID if the path is ‘/dev/xyz’
… is the this
the underlaying semantic ??

It is better to use always ‘name_open’ to setup a connection to
arbitrary designed resource managers??

Sorry … can’t work because ‘name_open’ doesn’t allow to specify an
absolute path …

Armin

Regards

Armin

PS: is there a downloadable tar ball of the CVS ??

chris

Armin <a-steinhoff@web_.de> wrote:

Hi,

Just a dumb question …

// attach point created by name_attach …

// get a fd for MsgSend … ATTACH_POINT== ‘myname’
if ((fd_a = name_open(ATTACH_POINT, 0)) == -1) {
return EXIT_FAILURE;
}

MsgSend(fd_a, … ) works.

// fd by a standard open …
if ((fd_b = open("/dev/name/local/myname", O_RDWR)) == -1) {
return EXIT_FAILURE;
}

MsgSend(fd_b, … ) doesn’t work > :frowning:

What’s different with fd_a and fd_b ???

Regards

Armin



\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Did it now … the problem seems to be the ‘open’ call.

Comes ‘open’ only back with a connection ID if the path is ‘/dev/xyz’
… is the this
the underlaying semantic ??

It is better to use always ‘name_open’ to setup a connection to
arbitrary designed resource managers??

Sorry … can’t work because ‘name_open’ doesn’t allow to specify an
absolute path …

I am confused. General resource managers function just fine with calls to
open(). What I am trying to say about the name_*() API is that it isn’t really
just a plain resource manager interface. I am personally unable to get into
details (only because a lack of detailed knowledge in the area) but I know that
there are going to be symatic differences between name_attach() and
resmgr_attach() that will probably preclude using the standard open() API on
an entry in /dev/name/…

chris


Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

Chris McKillop wrote:

Did it now … the problem seems to be the ‘open’ call.

Comes ‘open’ only back with a connection ID if the path is ‘/dev/xyz’
… is the this
the underlaying semantic ??

It is better to use always ‘name_open’ to setup a connection to
arbitrary designed resource managers??

Sorry … can’t work because ‘name_open’ doesn’t allow to specify an
absolute path …


I am confused.

Ditto … I have followed the call chain of open and name_open calls and
found out that
both library calls are calling _connect() with different parameters.
(_NTO_SIDE_CHANNEL …)

Who takes care about the correct interpretation of the file id
returned by
the open call ???

Regards

Armin


General resource managers function just fine with calls to
open(). What I am trying to say about the name_*() API is that it isn’t really
just a plain resource manager interface. I am personally unable to get into
details (only because a lack of detailed knowledge in the area) but I know that
there are going to be symatic differences between name_attach() and
resmgr_attach() that will probably preclude using the standard open() API on
an entry in /dev/name/…

chris


Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3C3B1734.C9482C6C@web_.de…

Ditto … I have followed the call chain of open and name_open calls and
found out that
both library calls are calling _connect() with different parameters.
(_NTO_SIDE_CHANNEL …)

Who takes care about the correct interpretation of the file id
returned by
the open call ???

I am also confused - From your original post, you’re saying that you can use
MsgSend/Recieve/Rely() on connectionID/Fd’s from name_open() but not with
those from open()? Can you post a test case so we can all see exactly what
you’re doing? Take a look on cvs at the read() function (/lib/c/1/read.c) -
it does a MsgSend() on the fd you pass in from an open() call.


Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

Adam Mallory <amallory@qnx.com> wrote:

Who takes care about the correct interpretation of the file id
returned by
the open call ???

I am also confused - From your original post, you’re saying that you can use
MsgSend/Recieve/Rely() on connectionID/Fd’s from name_open() but not with
those from open()? Can you post a test case so we can all see exactly what
you’re doing? Take a look on cvs at the read() function (/lib/c/1/read.c) -
it does a MsgSend() on the fd you pass in from an open() call.

If you look in lib/c/dispatch/name.c you will see that the resmgr_attach
is doing an attach of _FTYPE_NAME. Now, what this means is that internally
proc handles this mount differently. From what I can tell (in my quick
scan) it is going to handle name_opens()'s for the mount point and re-direct
connections. However, when you do a “normal” open() on the name entry in
/dev, proc handles that itself - probably so you can (in the future, today?)
extract some information on who owns the name space and other details.

chris

\

Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/