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.0/neutrino/technotes/gns_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