Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 15 Apr 2015 15:20:19 +0200 | From | Borislav Petkov <> | Subject | Re: [GIT PULL] kdbus for 4.1-rc1 |
| |
On Wed, Apr 15, 2015 at 12:25:55PM +0100, One Thousand Gnomes wrote: > dbus is not an appropriate design for a kernel messaging layer for a > variety of reasons. That's not to say dbus shouldn't be able to use a > fast kernel messaging layer, or that one shouldn't exist. > > dbus is basically a very large very specialized and somewhat flawed > policy engine on top of what should be simple messaging. The two need > splitting apart. > > Abstract low level messaging layers are not a new concept. V7 unix had > one experimentally. It's about getting the separation right. > > IMHO that probably involves getting the right people in the right place > together - dbus designers, MPI and realtime people, kernel folks and > possibly also some of the hardware messaging folk. > > In filesystem terms > > - stop writing a dbus only file system > - figure out what a messaging "vfs" looks like > - figure out what an clean low level kernel model looks like > - figure out what has to be where to put the policy in userspace > > What might also be worth review is how much dbus traffic actually ought to > be an object store implemented say with tmpfs and inotify type > functionality (or extensions of that) so that you can > set/read/enumerate/get change notifications on properties.
FWIW, this sounds really sane and makes a lot of sense to me. I'd be willing to give it some review cycles, as far as I can, when done this way.
-- Regards/Gruss, Boris.
ECO tip #101: Trim your mails when you reply. --
| ![\](/images/icornerr.gif) |