On Wed, Nov 26, 2014 at 01:25:18AM +0100, Lennart Poettering wrote:
> On Tue, 25.11.14 12:01, Thiago Macieira (thi...@kde.org) wrote:
[...]
> > > > === KDBUS_ATTACH_NAMES ===
> > > >
> > > > Documentation for metadata says that userspace must cope with some
> > > > metadata
> > > > not being deli
On Wed, 26.11.14 11:08, Thiago Macieira (thi...@kde.org) wrote:
> On Wednesday 26 November 2014 19:30:16 Lennart Poettering wrote:
> > > I must be misunderstanding something.
> >
> > The kernel enforces that each bus name is prefixed with "$UID-". This
> > is why the system bus is /sys/fs/kdbus/0
On Wednesday 26 November 2014 19:44:46 Lennart Poettering wrote:
> Now, that's the reason why acquirename/releasename need to be
> implemented client side. With that knowledge we can punch holes in the
> other calls too. For example, the GetConnectionUnixProcessID() call
> you brought up: let's now
On Wednesday 26 November 2014 19:30:16 Lennart Poettering wrote:
> > I must be misunderstanding something.
>
> The kernel enforces that each bus name is prefixed with "$UID-". This
> is why the system bus is /sys/fs/kdbus/0-system rather than just
> /sys/fs/kdbus/system.
>
> This makes sure that
On Wed, 26.11.14 10:10, Thiago Macieira (thi...@kde.org) wrote:
> On Wednesday 26 November 2014 12:35:33 Lennart Poettering wrote:
> > > Aside from the connection-control mechanisms (AddMatch, RemoveMatch), did
> > > you see any problems?
> >
> > It was primarily about that, but it is easy to con
On Wed, 26.11.14 10:04, Thiago Macieira (thi...@kde.org) wrote:
> On Wednesday 26 November 2014 12:27:16 Lennart Poettering wrote:
> > > Please also note that the autostart solution has a valid use-case which is
> > > when a D-Bus application is launched in an environment where no bus had
> > > be
On Wednesday 26 November 2014 12:35:33 Lennart Poettering wrote:
> > Aside from the connection-control mechanisms (AddMatch, RemoveMatch), did
> > you see any problems?
>
> It was primarily about that, but it is easy to construct races with
> this for most of the other driver calls as well.
[snip]
On Wednesday 26 November 2014 12:27:16 Lennart Poettering wrote:
> > Please also note that the autostart solution has a valid use-case which is
> > when a D-Bus application is launched in an environment where no bus had
> > been started before. I understand this is out-of-scope for kdbus, since
> >
On 25/11/14 23:46, David Herrmann wrote:
> In particular, if gdbus runs AddMatch(), it assumes the match takes
> effect immediately. If it sends a method call to another service after
> installing the match, and this triggers a signal, gdbus assumes the
> AddMatch() call to have succeeded (without
On Tue, 25.11.14 18:46, Thiago Macieira (thi...@kde.org) wrote:
> On Wednesday 26 November 2014 00:46:50 David Herrmann wrote:
> > We had "systemd-bus-driverd", which implemented org.freedesktop.DBus
> > as normal service. However, this didn't work out as many dbus clients
> > rely on this service
On Tue, 25.11.14 18:32, Thiago Macieira (thi...@kde.org) wrote:
> On Wednesday 26 November 2014 01:25:18 Lennart Poettering wrote:
> > > Thinking of non-system buses here.
> > >
> > > If the variable is empty, I agree that it should have an equivalent of an
> > > "autostart" mechanism, but I disa
On Wednesday 26 November 2014 00:46:50 David Herrmann wrote:
> We had "systemd-bus-driverd", which implemented org.freedesktop.DBus
> as normal service. However, this didn't work out as many dbus clients
> rely on this services to not be re-ordered in regard to external
> requests.
>
> In particul
On Wednesday 26 November 2014 01:25:18 Lennart Poettering wrote:
> > Thinking of non-system buses here.
> >
> > If the variable is empty, I agree that it should have an equivalent of an
> > "autostart" mechanism, but I disagree on the solution and I also disagree
> > that distros should leave it e
On Wed, 26.11.14 00:46, David Herrmann (dh.herrm...@gmail.com) wrote:
> Custom endpoints do _not_ create new buses. Really. You could create a
> custom bus and use it for just 2 connections, but then you could also
> just use socketpair(2). Note that there was some discussion on
> "anonymous buses
On Tue, 25.11.14 12:01, Thiago Macieira (thi...@kde.org) wrote:
> > Well, we don't need any env var really, as we enforce that the UID of
> > the user is included in the name of their bussess, and the busses are
> > cleaned up when the registrar dies. We don't have the risk of leaving
> > old buss
Hi Thiago
On Tue, Nov 25, 2014 at 9:01 PM, Thiago Macieira wrote:
> On Tuesday 25 November 2014 17:11:36 Lennart Poettering wrote:
>> > == org.freedesktop.DBus connection ==
>> >
>> > Will systemd-kdbus provide that name on the bus so applications that make
>> > calls directly be able to continue
On Tuesday 25 November 2014 17:11:36 Lennart Poettering wrote:
[snip]
Thanks for raising the resource limits.
> > == DBUS__BUS_ADDRESS ==
> >
> > We probably discussed this. Should we specify that the address on the
> >
> > environment variable should be of the form:
> > kdbus:path=/sys/fs
On Mon, 24.11.14 18:40, Thiago Macieira (thi...@kde.org) wrote:
> Another thought that comes to mind: should we reserve the entire highest bit
> in connection IDs for broadcasts? It would allow for the existence of
> multicast groups in the future.
I discussed this quickly with the kdbus guys,
On Mon, 24.11.14 18:40, Thiago Macieira (thi...@kde.org) wrote:
> I'm wondering if the same solution should be applied to the session bus. That
> would have the unfortunate effect that applications that aren't ported to
> know
> about kdbus will always fallback to proxy functionality. It would
Sorry for the delay in replying. I didn't have time until after KLF...
On Wednesday 01 October 2014 14:33:01 Simon McVittie wrote:
> System bus access-control policy
>
[snip]
> If I remember correctly, the least bad solution anyone could think of
> was to introduce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/10/2014 15:33, Simon McVittie wrote:
[cut]
> Resource limits ===
>
> Some resource limits are lower in kdbus than in dbus-daemon.
>
> In kdbus, the number of unread messages per recipient is limited to
> 256, with up to 16 per uid;
On Wed, 01.10.14 14:33, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
Thanks a ton for reviewing kdbus and its concepts!
(Also, sorry for not responding earlier to all the dbus/kdbus traffic
in the last month, I was travelling.)
> System bus access-control policy
> =
Hi Simon,
On 10/01/2014 03:33 PM, Simon McVittie wrote:
> (Cc'd to the systemd mailing list because sd-bus is the reference
> implementation of the user-space side of kdbus, but please join the dbus
> list and follow-up there if you are interested in D-Bus.)
>
> I've recently been looking at kdbu
(Cc'd to the systemd mailing list because sd-bus is the reference
implementation of the user-space side of kdbus, but please join the dbus
list and follow-up there if you are interested in D-Bus.)
I've recently been looking at kdbus as a transport for D-Bus messages,
and how compatible or otherwis
24 matches
Mail list logo
