Skip navigation.
Home
The QNX Community Portal

View topic - Replacement for qnx_name_nodes()

Replacement for qnx_name_nodes()

Read-only archive of qnx.porting (Discuss migrating applications from QNX4, VxWorks, PSOS, or Linux to QNX Neutrino) at inn.qnx.com

Replacement for qnx_name_nodes()

Postby Bert Menkveld » Wed Jul 18, 2007 3:21 pm

In QNX 4 there is a function qnx_name_nodes() that returns all the node
numbers where a given global name has been registered. The migration guide
points out that this function is "No longer supported." in QNX Neutrino.
While that does eliminate the need to look further, it doesn't do much to
help me find a solution.

Globally registered names show up in /dev/name/global, as doc'ed. However,
I've also noticed that each name is actually a directory, containing a very
interesting looking file name. Multiple global registrations of the same
name generate multiple entries within the name directory. The file names
consist of a bunch of numbers, seperated by commas. One of these numbers is
clearly the PID of the owner process. I'm hoping that one of the other
numbers is the Node Descriptor for the node on which the owner process
lives. I haven't found any docs describing the significance of these files
names. Can anyone point me to any documentation for these names, and what
use can be made of them?

Regards,

Bert

--
Bert Menkveld
P. Eng.
B&E Technologies
bert@betech.biz
Ph: 519-669-0950
Bert Menkveld
 

Re: Replacement for qnx_name_nodes()

Postby David Gibbs » Tue Jul 31, 2007 10:03 pm

Bert Menkveld <bert@betech.biz> wrote:

I'll bet these are the same "funny" filenames you would see if you
looked under the (normally invisible, but actually there) /proc/mount
directory.

I'm pretty sure there is a (nd,pid,chid) triplicate in there, but I don't
think it is officially documented anywhere.

-David

In QNX 4 there is a function qnx_name_nodes() that returns all the node
numbers where a given global name has been registered. The migration guide
points out that this function is "No longer supported." in QNX Neutrino.
While that does eliminate the need to look further, it doesn't do much to
help me find a solution.

Globally registered names show up in /dev/name/global, as doc'ed. However,
I've also noticed that each name is actually a directory, containing a very
interesting looking file name. Multiple global registrations of the same
name generate multiple entries within the name directory. The file names
consist of a bunch of numbers, seperated by commas. One of these numbers is
clearly the PID of the owner process. I'm hoping that one of the other
numbers is the Node Descriptor for the node on which the owner process
lives. I haven't found any docs describing the significance of these files
names. Can anyone point me to any documentation for these names, and what
use can be made of them?

Regards,

Bert

--
Bert Menkveld
P. Eng.
B&E Technologies
bert@betech.biz
Ph: 519-669-0950



--
David Gibbs
QNX Training Services
dagibbs@qnx.com
David Gibbs
 

Re: Replacement for qnx_name_nodes()

Postby Bert Menkveld » Wed Aug 01, 2007 12:44 pm

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:f8obio$73a$1@inn.qnx.com...
Bert Menkveld <bert@betech.biz> wrote:

I'll bet these are the same "funny" filenames you would see if you
looked under the (normally invisible, but actually there) /proc/mount
directory.

I'm pretty sure there is a (nd,pid,chid) triplicate in there, but I don't
think it is officially documented anywhere.

Thanks for the response. As it happens, a smart colleague did find some
documentation describing these "funny" file names:

http://www.qnx.com/developers/docs/6.3. ... howto.html

Unfortunately the ND (node descriptor) part of the file name seems to be
strictly from the perspective of the node on which the gns server is
running, which makes it useless elsewhere on the network. Instead I've
ended up using the node name contained in the full path of each of these
file names.

Regards,

Bert

In QNX 4 there is a function qnx_name_nodes() that returns all the node
numbers where a given global name has been registered. The migration
guide
points out that this function is "No longer supported." in QNX Neutrino.
While that does eliminate the need to look further, it doesn't do much to
help me find a solution.

Globally registered names show up in /dev/name/global, as doc'ed.
However,
I've also noticed that each name is actually a directory, containing a
very
interesting looking file name. Multiple global registrations of the same
name generate multiple entries within the name directory. The file names
consist of a bunch of numbers, seperated by commas. One of these numbers
is
clearly the PID of the owner process. I'm hoping that one of the other
numbers is the Node Descriptor for the node on which the owner process
lives. I haven't found any docs describing the significance of these
files
names. Can anyone point me to any documentation for these names, and
what
use can be made of them?

Regards,

Bert

--
Bert Menkveld
P. Eng.
B&E Technologies
bert@betech.biz
Ph: 519-669-0950



--
David Gibbs
QNX Training Services
dagibbs@qnx.com
Bert Menkveld
 

Re: Replacement for qnx_name_nodes()

Postby Guest » Sun Aug 05, 2007 2:07 am

The "funny name" is nd,pid,chid,handle,ftype, which is, the same
as /proc/mount.

I could be wrong but I think the nd is translated to local. That is,
if you run gns client and gns server, the nd is local to the client
machine if you do a ls /dev/name/global on client machine.

You may confirm this by doing a netmgr_ndtostr() to find out.

Also, I think if you name_open() the "funnay name"
(/dev/name/global/services/0,1,2,3,4), you ended up directly connect
to "that" service provider.

-xtang

Bert Menkveld <bert@betech.biz> wrote:
"David Gibbs" <dagibbs@qnx.com> wrote in message
news:f8obio$73a$1@inn.qnx.com...
Bert Menkveld <bert@betech.biz> wrote:

I'll bet these are the same "funny" filenames you would see if you
looked under the (normally invisible, but actually there) /proc/mount
directory.

I'm pretty sure there is a (nd,pid,chid) triplicate in there, but I don't
think it is officially documented anywhere.

Thanks for the response. As it happens, a smart colleague did find some
documentation describing these "funny" file names:

http://www.qnx.com/developers/docs/6.3. ... howto.html

Unfortunately the ND (node descriptor) part of the file name seems to be
strictly from the perspective of the node on which the gns server is
running, which makes it useless elsewhere on the network. Instead I've
ended up using the node name contained in the full path of each of these
file names.

Regards,

Bert

In QNX 4 there is a function qnx_name_nodes() that returns all the node
numbers where a given global name has been registered. The migration
guide
points out that this function is "No longer supported." in QNX Neutrino.
While that does eliminate the need to look further, it doesn't do much to
help me find a solution.

Globally registered names show up in /dev/name/global, as doc'ed.
However,
I've also noticed that each name is actually a directory, containing a
very
interesting looking file name. Multiple global registrations of the same
name generate multiple entries within the name directory. The file names
consist of a bunch of numbers, seperated by commas. One of these numbers
is
clearly the PID of the owner process. I'm hoping that one of the other
numbers is the Node Descriptor for the node on which the owner process
lives. I haven't found any docs describing the significance of these
files
names. Can anyone point me to any documentation for these names, and
what
use can be made of them?

Regards,

Bert

--
Bert Menkveld
P. Eng.
B&E Technologies
bert@betech.biz
Ph: 519-669-0950



--
David Gibbs
QNX Training Services
dagibbs@qnx.com

Guest
 

Re: Replacement for qnx_name_nodes()

Postby Bert Menkveld » Tue Aug 07, 2007 11:50 am

xtang@qnx.com wrote:
The "funny name" is nd,pid,chid,handle,ftype, which is, the same
as /proc/mount.

I could be wrong but I think the nd is translated to local. That is,
if you run gns client and gns server, the nd is local to the client
machine if you do a ls /dev/name/global on client machine.

You may confirm this by doing a netmgr_ndtostr() to find out.

I did try that, and found that the nd does *not*, in fact, get translated to
make sense on the local machine. It seems to be simply the value that is
correct on the machine running the gns server.

Mind you, I only have a 2-node network to test on, so there may be larger
issues escaping me.

Also, I think if you name_open() the "funnay name"
(/dev/name/global/services/0,1,2,3,4), you ended up directly connect
to "that" service provider.

Interesting. I'll keep that in mind as it just might prove useful.

Thanks for your help with this.

Regards,

--
Bert Menkveld
P. Eng.
B&E Technologies
bert@betech.biz
Ph: 519-669-0950

Bert Menkveld <bert@betech.biz> wrote:
"David Gibbs" <dagibbs@qnx.com> wrote in message
news:f8obio$73a$1@inn.qnx.com...
Bert Menkveld <bert@betech.biz> wrote:

I'll bet these are the same "funny" filenames you would see if you
looked under the (normally invisible, but actually there)
/proc/mount directory.

I'm pretty sure there is a (nd,pid,chid) triplicate in there, but I
don't think it is officially documented anywhere.

Thanks for the response. As it happens, a smart colleague did find
some documentation describing these "funny" file names:

http://www.qnx.com/developers/docs/6.3. ... howto.html

Unfortunately the ND (node descriptor) part of the file name seems
to be strictly from the perspective of the node on which the gns
server is running, which makes it useless elsewhere on the network.
Instead I've ended up using the node name contained in the full path
of each of these file names.

Regards,

Bert

In QNX 4 there is a function qnx_name_nodes() that returns all the
node numbers where a given global name has been registered. The
migration guide
points out that this function is "No longer supported." in QNX
Neutrino. While that does eliminate the need to look further, it
doesn't do much to help me find a solution.

Globally registered names show up in /dev/name/global, as doc'ed.
However,
I've also noticed that each name is actually a directory,
containing a very
interesting looking file name. Multiple global registrations of
the same name generate multiple entries within the name directory.
The file names consist of a bunch of numbers, seperated by commas.
One of these numbers is
clearly the PID of the owner process. I'm hoping that one of the
other numbers is the Node Descriptor for the node on which the
owner process lives. I haven't found any docs describing the
significance of these files
names. Can anyone point me to any documentation for these names,
and what
use can be made of them?

Regards,

Bert

--
Bert Menkveld
P. Eng.
B&E Technologies
bert@betech.biz
Ph: 519-669-0950



--
David Gibbs
QNX Training Services
dagibbs@qnx.com
Bert Menkveld
 


Return to qnx.porting

Who is online

Users browsing this forum: No registered users and 1 guest