Havoc Pennington hp at redhat.com
Sun Sep 10 12:30:55 PDT 2006

btw, a specific change I think could make sense but may not is to make 
the dbus-sysdeps.h file descriptor operations socket-specific. Maybe put 
_socket in the names when the function could conceivably work on a file, 


Then in dbus-sysdeps-unix.h there could be maybe a dbus_read_file() 
and/or dbus_read_socket_or_file(). For unix the implementation of course is:

  /* current code */



After renaming these, could go through each compilation error about 
missing _dbus_read() and be sure the appropriate function is used. i.e. 
if the fd is known to be a socket, use read_socket, known to be a file, 
use read_file, etc.

If there are any uses of dbus_read_socket_or_file, which there may not 
be, then if that function is in dbus-sysdeps-unix.h we would then be 
able to tell that the file using dbus_read_socket_or_file was unix-specific.

Once this is done I think dbus-server-unix.c for example could be 
renamed to dbus-server-socket.c and no longer include unistd.h or 
dbus-sysdeps-unix.h, it could include just dbus-sysdeps.h and use the 
socket functions.

There would still be a dbus-server-unix.c perhaps but containing only 
the function _dbus_server_new_for_domain_socket().

Alternatively - maybe dbus-sysdeps-unix.h is not always right. Another 
approach for e.g. the unix domain socket functions 
_dbus_listen_unix_socket, etc. would be to make them always fail on 
Windows - the Windows implementation just returns an error.
That would have the desired effect i.e. if you tried to use a unix: 
address on Windows, the error "unix sockets not supported on Windows" 
would be printed. This is the same way we're dealing with the public API 
that has _unix in it.

If we made this change then there's no dbus-server-unix.c, just 

That would not work as well for _dbus_read_socket_or_file() though, 
probably trying to use _dbus_read_socket_or_file() should fail at 
compile time on Windows, since the right thing won't happen if it just 
fails at runtime. So sysdeps-unix.h might make sense for 

I'm not sure sysdeps-unix.h will have anything in it to be honest, if 
sockets are not unix-specific, read_socket_or_file() never gets used, 
and e.g. connect_unix_socket and read_credentials_unix_socket simply 
fail with an error on Windows, then that would work out just fine.

The only thing that I still consider a little fishy is all the 
unix-specific gid/uid/pid stuff in dbus-sysdeps.h, but as long as any 
weird made-up ids don't make it out of the dbus process, I think it will 
be OK.

I guess I'm almost stating the obvious - a dbus-sysdeps-unix.h should 
not be necessary *if* there's no need for -unix files elsewhere in the 
source tree - i.e. if everything in dbus-sysdeps.h is an appropriate 
abstraction that works (or fails in the right way) on both platforms.

The thing I'd consider bad is to try to actually implement a thing like 
connect_unix_socket on windows; it needs to fail either at compile time 
or at run time. dbus-sysdeps-unix.h is an idea for how to fail it at 
compile time, and at runtime it could just throw a DBusError.

We want to avoid things labeled unix that really work on both platforms, 
and also things not labeled unix that really work only on unix.


More information about the dbus mailing list