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
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
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