No, we do not do the "abstract name" (though it is not harder to do so).

I believe the configure file in DBUS actually do a test on this feature,
and the source is also happy
if the OS does not support "abstract name".

On core_network 6.4, we made the stack FAIL if a Unix domain path
started with a NULL, this way,
the configure would detect, and do the right thing.

Unfortunately, on 6.3.2 the configure fill will mess up things badly.
You can try modify the configure
file to exclude the test of "abstract name" and specifically set it to
fail, to get your porting going.

By the way, if you happened to get into the bad status (no . and ..),
kill the stack (the io-net process) 
should bring everything back. (you then have to restart it by hand of
cause).

If you are not using configure file, but rather messing with the source
yourself, either define the flag
to tell DBUS not to do it, or modify the source so it won't have a
leading NULL in path.

-xtang


> -----Original Message-----
> From: Glenn Schmottlach [mailto:community-noreply@qnx.com] 
> Sent: Friday, August 08, 2008 4:48 PM
> To: ostech-core_os
> Subject: Abstract Domain Sockets (Unix domain sockets)
> 
> 
> I am in the process of porting DBUS from Linux onto QNX 
> 6.3.2. DBUS uses unix domain sockets as the communications 
> channel between services. Fortunately, it appears that QNX 
> does support unix domain sockets. Specifically, however, DBUS 
> seems to want to use a variant called "abstract" domain 
> sockets that are supported under Linux (and I think Sun). I 
> guess "abstract" domain sockets appear in the filesystem but 
> they're not quite "real". Regardless, they're signified by 
> stuffing a NULL (\0) as the first byte of the path in the 
> address structure (as seen below):
> 
> addr.sun_path[0] = '\0'; /* this is what says "use abstract" */
> 
> The actual path to the "domain" socket is appended to the end
> 
> strncpy (&addr.sun_path[1], path, path_len);
> 
> Unfortunately, it appears QNX chokes hard on this and 
> actually corrupts the '.' and '..' entries in the filesystem 
> after a call to "bind". I discovered this when running an 
> autoconf "configure" script and it hung at the end. When I 
> hit ctrl-c to kill the build I was left at the shell prompt. 
> From there I could no longer "ls" the current directory I was 
> in (although 'ls' would work if I specified a complete path). 
> I suspect one of the configure tests tried to execute an 
> abstract domain socket test application to determine if it 
> was supported (and apparently it believes so from the output 
> of config.log). Needless to say, the only recovery is to 
> restart QNX (hard to believe a shell script can so easily 
> take out the QNX filesystem).
> 
> So, the question I have is whether QNX supports abstract 
> domain sockets, and if so, how do you signify that they are 
> abstract to the OS?
> 
> Also, I suspect QNX might want to "harden" or scrub the input 
> parameters to "bind" a little more carefully and at least 
> return an error if abstract sockets aren't supported. No 
> sense trashing the file system.
> 
> 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post11598
> 
> 

Hi Glenn:

We specifically look for and invalidate abstract UD sockets with the new
version of our networking stack so that you don't see this corruption
(see commit
http://community.qnx.com/sf/scm/do/viewCommit/projects.networking/scm.Co
re_Networking/cmmt11186).

The older, currently shipping version of the stack doesn't behave
properly, unfortunately, as you have found out.

   Robert.



-----Original Message-----
From: Glenn Schmottlach [mailto:community-noreply@qnx.com] 
Sent: Friday, August 08, 2008 4:48 PM
To: ostech-core_os
Subject: Abstract Domain Sockets (Unix domain sockets)


I am in the process of porting DBUS from Linux onto QNX 6.3.2. DBUS uses
unix domain sockets as the communications channel between services.
Fortunately, it appears that QNX does support unix domain sockets.
Specifically, however, DBUS seems to want to use a variant called
"abstract" domain sockets that are supported under Linux (and I think
Sun). I guess "abstract" domain sockets appear in the filesystem but
they're not quite "real". Regardless, they're signified by stuffing a
NULL (\0) as the first byte of the path in the address structure (as
seen below):

addr.sun_path[0] = '\0'; /* this is what says "use abstract" */

The actual path to the "domain" socket is appended to the end

strncpy (&addr.sun_path[1], path, path_len);

Unfortunately, it appears QNX chokes hard on this and actually corrupts
the '.' and '..' entries in the filesystem after a call to "bind". I
discovered this when running an autoconf "configure" script and it hung
at the end. When I hit ctrl-c to kill the build I was left at the shell
prompt. From there I could no longer "ls" the current directory I was in
(although 'ls' would work if I specified a complete path). I suspect one
of the configure tests tried to execute an abstract domain socket test
application to determine if it was supported (and apparently it believes
so from the output of config.log). Needless to say, the only recovery is
to restart QNX (hard to believe a shell script can so easily take out
the QNX filesystem).

So, the question I have is whether QNX supports abstract domain sockets,
and if so, how do you signify that they are abstract to the OS?

Also, I suspect QNX might want to "harden" or scrub the input parameters
to "bind" a little more carefully and at least return an error if
abstract sockets aren't supported. No sense trashing the file system.



_______________________________________________
OSTech
http://community.qnx.com/sf/go/post11598