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 [[service_solahart_jakarta_selatan__082122541663/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
|
