summaryrefslogtreecommitdiff
path: root/open_issues/dbus_in_linux_kernel.mdwn
blob: 6f83db039685775174dfa8adee39546c978076df (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
[[!meta copyright="Copyright © 2010, 2013, 2014 Free Software Foundation,
Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!meta title="AF_BUS, D-Bus, and the Linux kernel"]]

Might be interesting to watch how this develops.

[[!toc]]


# IRC, freenode, #hurd, about 2010-08/2010-09

    <neal> check this out:
    <neal> someone is working on implementing dbus in linux
    <neal> linux finally gets mach ipc ;-)
    <marcusb> it's old news though, unless there is an update
    <marcusb> and I think it was only the client?
    <neal> youpi : someone is adding dbus ipc to the linux kernel
    <neal> marcusb: I just heard about it.
    <youpi> (it's crazy how this drives backward compared to a hurdish approach)
    <youpi> what is the motivation for moving to the kernel?
    <neal> context switch overhead
    <azeem_> they wanna use it to talk to device drivers? :)
    <kilobug> well, they did that with the in-kernel web server, but they
      abandonned it later on
    <neal> azeem: I don't think so.
    <neal> dbus in the kernel is actually good for the Hurd as dbus IPC is
      basically neutered Mach IPC
    <marcusb> I don't think anybody wants to put the dbus server in the kernel
    <neal> well, there is at least one person
    <marcusb> maybe this is a different news from the one I read
    <neal> Alban Crequy (albanc) is working out.  He works for collabora, fwiw

<http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/>

    <marcusb> what I read was about hal etc
    <marcusb> so that you don't need a user space daemon to glue the kernel to the
      dbus world
    <neal> I don't think that is what he is talking about
    <marcusb> I can't find it anymore though.  I mentioned it in this channel at
      the time though, so it should be in the backlog
    <marcusb> neal, yeah could very well be a separate thing
    <marcusb> neal, dbus does have marginal support for fd passing though, and some
      attempts on the mailing list to make "fds" an official type in the message
      failed (as far as I could see, I didn't read the whole discussion)
    <marcusb> so no mach ipc just yet
    <neal> wrong
    <neal> FD handling is in 1.4
    <neal> type o, if I'm not mistaken
    <marcusb> then the discussion moved on from initial rejection
    <neal> no, 'h'
    <marcusb> I'm out of date by two months
    <marcusb> ok
    <guillem> neal: AFAIR Marcel Holtmann talked about dbus in-kernel several years
      ago, but he never ended up implementing it, or there were rumors he had
      private "working code"

  * Related Mailing List Discussion

      * [\[PATCH 0/5\] RFC: Multicast and filtering features on
        AF_UNIX](http://article.gmane.org/gmane.linux.kernel/1040481),
        2010-09-24


# 2013-02

[AF_BUS, D-Bus, and the Linux
kernel](http://www.kroah.com/log/linux/af_bus.html), Greg Kroah-Hartman,
2013-02-08.


# kdbus


## IRC, freenode, #hurd, 2014-01-28

    <braunr> i would like to see things like dbus and zeromq use an optimized
      microkernel transport one day
    <teythoon> we could port kdbus >,<
    <braunr> why not
    <braunr> you port cgroups first
    <teythoon> exactly
    <braunr> :p

[[systemd]].


## IRC, freenode, #hurd, 2014-02-23

In context of [[linux_as_the_kernel]], *IRC, freenode, #hurd, 2014-02-23*.

    <desrt> mach seems like this really simple thing when you first explain
      what a microkernel is
    <braunr> and because of that, i think it's better to start the right
      solution directly
    <braunr> it looks simple, it's clearly not
    <desrt> but i did a bit of looking into it... it's a bit non-trivial after
      all :)
    <braunr> mach ipc is over complicated and error prone
    <braunr> it leads to unefficient communication compared to other solutions
      such as what l4 does
    <desrt> ya -- i hear that this is a big part of the performance hit
    <braunr> that's why i've started x15
    <desrt> i was also doing some reading about how it's based on mapping
      memory segments between processes
    <braunr> first, it was a mach clone, but since i've come to know mach
      better, it's now a "spiritual" mach successor .. :)
    <desrt> these are two issues that we've been dealing with at another
      level... in the design of kdbus
    <braunr> ah kdbus :)
    <desrt> this is something that started with my masters thesis a long time
      ago...
    <braunr> ah you too
    <desrt> first thing we did is make the serialisation format so that all
      messages are valid and therefore never need to be checked
    <desrt> (old dbus format requires checks at every step on the way)
    <braunr> looks interesting
    <desrt> then of course we cut the daemon out
    <desrt> but some other interesting things: security is super-simple... it's
      based enirely on endpoints
    <desrt> either you're allowed to send messages between two processes or
      you're not
    <desrt> there is no checking for message types, for example
    <braunr> yes
    <desrt> and the other thing: memory mapping is usually bad
    <braunr> that's what i mean when i say mach ipc is over complicated
    <braunr> it depends
    <desrt> the kdbus guys did some performance testing and found out that if
      the message is less than ~512k then the cost of invalidating the TLB in
      order to change the memory mapping is higher than the cost of just
      copying the data
    <braunr> yes, we know that too
    <braunr> that's why zero copy isn't the normal way of passing small amounts
      of data over mach either
    <desrt> nice
    <desrt> i got the impression in some of my reading (wikipedia, honestly)
      that memory mapping was being done all the time
    <braunr> well
    <braunr> no it's not
    <braunr> memory mapping is unfortunately a small fraction of the
      performance overhead
    <desrt> that's good :)
    <braunr> that being said
    <braunr> memory mapping can be very useful
    <braunr> for example, it's hard for us to comply with posix requirements of
      being able to read/write at least 2G of data in a single call
    <braunr> weird bugs occur beyond 512M iirc
    <braunr> you do want memory mapping for that
    <desrt> ya... for things of this size.... you don't want to copy that
      through a socket :)
    <braunr> monolithic kernels have it naturally, since the kernel is mapped
      everywhere
    <braunr> for microkernels, it's a little more complicated
    <braunr> and the problem gets worse on smp
    <braunr> again, that's why i preferred starting a new kernel instead of
      reusing linux