mirror of
https://gitlab.freedesktop.org/dbus/dbus.git
synced 2026-01-06 04:50:14 +01:00
f349e6b8c5
* dbus/dbus-object-tree.c (handle_default_introspect_and_unlock):
fix a double-unlock
* dbus/dbus-connection.c
(_dbus_connection_detach_pending_call_unlocked): add this
Initial semi-correct pass through to fix thread locking; there are
still some issues with the condition variable paths I'm pretty
sure
* dbus/dbus-server.c: add a mutex on DBusServer and appropriate
lock/unlock calls
* dbus/dbus-connection.c (_dbus_connection_do_iteration_unlocked):
rename to add _unlocked
(struct DBusConnection): move "dispatch_acquired" and
"io_path_acquired" to use only one bit each.
(CONNECTION_LOCK, CONNECTION_UNLOCK): add checks with !DBUS_DISABLE_CHECKS
(dbus_connection_set_watch_functions): hacky fix to reentrancy
(_dbus_connection_add_watch, _dbus_connection_remove_watch)
(_dbus_connection_toggle_watch, _dbus_connection_add_timeout)
(_dbus_connection_remove_timeout)
(_dbus_connection_toggle_timeout): drop lock when calling out to
user functions; done in a hacky/bad way.
(_dbus_connection_send_and_unlock): add a missing unlock
(_dbus_connection_block_for_reply): add a missing unlock
* dbus/dbus-transport.c (_dbus_transport_get_is_authenticated):
drop lock in a hacky probably unsafe way to call out to user
function
120 lines
4.5 KiB
Text
120 lines
4.5 KiB
Text
Important for 1.0
|
|
===
|
|
|
|
- Audit @todo and FIXME for security issues
|
|
|
|
- The convenience functions in dbus-bus.h should perhaps have
|
|
the signatures that they would have if they were autogenerated
|
|
stubs. e.g. the acquire service function. We should also evaluate
|
|
which of these functions to include, in light of the fact that
|
|
GLib/Qt native stubs will probably also exist.
|
|
|
|
- the "break loader" and valid/invalid message tests are all disabled;
|
|
they need to be fixed and re-enabled with the new message args stuff.
|
|
I think I want to drop the .message files thing and just have code
|
|
that generates messages, more like the tests for
|
|
dbus-marshal-recursive.c (this is mostly done now, just needs some
|
|
cleanup)
|
|
|
|
- need to define bus behavior if you send a message to
|
|
yourself; is it an error, or allowed? If allowed,
|
|
we need to have a test for it in the test suite.
|
|
|
|
- validate dict entry number of fields
|
|
|
|
- just before 1.0, try a HAVE_INT64=0 build and be sure it runs
|
|
|
|
- in dbus-keyring.c, enforce that the keyring dir is not
|
|
world readable/writable
|
|
|
|
- Ping isn't handled
|
|
|
|
- fix introspection format to handle all signatures
|
|
|
|
- make the mutex/condvar functions private
|
|
|
|
Important for 1.0 GLib Bindings
|
|
===
|
|
|
|
- finish dbus-glib-tool support for adding introspection
|
|
data to GObject and autoexporting GObject using same
|
|
|
|
- Need to make sure that dbus-glib.h never returns any
|
|
dbus_malloc() memory, only g_malloc().
|
|
dbus_g_proxy_end_call() is the major offender.
|
|
|
|
- DBusGProxy doesn't emit "destroy" when it should
|
|
|
|
Might as Well for 1.0
|
|
===
|
|
|
|
- add dbus_message_has_path(), maybe has_member/interface
|
|
|
|
- connection_open/connection_disconnect lacks symmetry, open/close
|
|
or connect/disconnect
|
|
|
|
- protocol version in each message is pretty silly
|
|
|
|
Can Be Post 1.0
|
|
===
|
|
|
|
- change .service files to allow Names=list in addition to Name=string
|
|
|
|
- The message bus internal code still says "service" for
|
|
"name", "base service" for "unique name", "activate" for
|
|
"start"; would be nice to clean up.
|
|
|
|
- Property list feature on message bus (list of properties associated
|
|
with a connection). May also include message matching rules
|
|
that involve the properties of the source or destination
|
|
connection.
|
|
|
|
- Disconnecting the remote end on invalid UTF-8 is probably not a good
|
|
idea. The definition of "valid" is slightly fuzzy. I think it might
|
|
be better to just silently "fix" the UTF-8, or perhaps return an error.
|
|
|
|
- build and install the Doxygen manual in Makefile when --enable-docs
|
|
|
|
- if you send the same message to multiple connections, the serial number
|
|
will only be right for one of them. Probably need to just write() the serial
|
|
number, rather than putting it in the DBusMessage, or something.
|
|
|
|
- perhaps the bus driver should have properties that reflect attributes
|
|
of the session, such as hostname, architecture, operating system,
|
|
etc. Could be useful for code that wants to special-case behavior
|
|
for a particular host or class of hosts, for example.
|
|
|
|
- currently the security policy stuff for messages to/from
|
|
the bus driver is kind of strange; basically it's hardcoded that
|
|
you can always talk to the driver, but the default config file
|
|
has rules for it anyway, or something. it's conceptually
|
|
screwy at the moment.
|
|
|
|
- when making a method call, if the call serial were globally unique,
|
|
we could forward the call serial along with any method calls made
|
|
as a result of the first method call, and allow reentrancy that was
|
|
strictly part of the call stack of said method call. But I don't
|
|
really see how to do this without making the user pass around the
|
|
call serial to all method calls all the time, or disallowing
|
|
async calls.
|
|
|
|
If done post 1.0 will probably be an optional/ugly-API type
|
|
of thing.
|
|
|
|
- I don't want to introduce DBusObject, but refcounting and object
|
|
data could still be factored out into an internal "base class"
|
|
perhaps.
|
|
|
|
- document the auth protocol as a set of states and transitions, and
|
|
then reimplement it in those terms
|
|
|
|
- recursive dispatch, see dbus_connection_dispatch()
|
|
|
|
- do we need per-display activation; if so I'd like to do this by setting a
|
|
"display ID" property on screen 0, with a GUID, and keying activation by
|
|
said GUID. Otherwise you get all kinds of unrobust
|
|
string/hostname-based mess. per-screen is then done by appending screen number
|
|
to the display. If displays have a deterministic ID like this, you can
|
|
do per-display by simply including GUID in the service name.
|
|
|
|
- optimization and profiling!
|