Clarification on upstart-0.5 and dbus usage

[Marcel Holtmann]

Hi Garrett,

> >> Marcel, seems to think that just by allowing the implementation of
> >> alternatives to D-Bus in Upstart would cause bloating in Upstart. I find
> >> that argument without merit. There is a bunch of functions in nih/dbus.c
> >> which essentially define the D-Bus communication into Upstart. The rest
> >> of upstart don't seem to have much that is really D-Bus specific. So as
> >> long we as we continue to keep the D-Bus specific stuff to the
> >> nih/dbus.c files i.e. outside of the main upstart code, people could
> >> implement alternatives to nih/dbus.c and use the Makefile to decide
> >> which one gets compiled in. Why would this bloat Upstart?
> >
> > That won't work. Looks like a good idea, but in the end doesn't work. I
> > have been there and tried it. This is nearly impossible to maintain and
> > create a complex abstraction. It will bloat your code. If you don't
> > believe me, that is perfectly fine. I am not going to stop you from
> > doing it, but I did warn you :)
> 
> Agreed. Maintaining a second IPC layer would be unwise for continued work.
> 
> D-Bus isn't going away anytime soon from what I can see and specs can
> change between versions if we pose a good enough case to the D-Bus
> folks; we might be able to 'contract out' D-Bus folk's help too if we
> have a clear set of requirements, pose a good case, and are willing to
> help contribute (provide funds, manpower, other resources, etc to the
> project) to motivate our combined goals.
> 
> One solution that was brought up a while ago though is we could
> essentially write an dbusd 'replacement' with a limited subset of
> D-Bus protocol instructions, such that we could maintain Cisco I.P.
> absolutely while being flexible to include D-Bus in the base system in
> the future. Maintaining it of course would require more responsibility
> from our end and would in the end prove to be more involved than just
> contributing essential components back to the community and working
> with the community to positively evolve said source code.

I think that is a really good idea. Start looking at the D-Bus
specification and look at the protocol. If you write your own daemon for
handling the D-Bus system bus, you can do it really small in the case
you have constraint requirements. So for example:

Target a specific OS, Linux in your case, and don't bother with compat
or old stuff. Use what the latest Linux kernels allows you to do.

If you have a constraint set of users in your system. Maybe root and
another one. Then you don't need the complex security handling that the
current implementation provides. You can simplify this a lot. If
everything runs as root anyway and you don't use SELinux, then you can
actually throw it away completely.

The bus daemon is a message dispatcher and thus you can do a lot of
optimization for the message parsing. For example don't bother with the
body, simply hand it over to its destination etc.

Only provide a system bus if you don't need the session bus. So that
extra code for session handling is not unneeded. Also the service
activation part can go away since you have Upstart.

And there is more that can be done. My estimate is that in the end you
end up with a simple and small dbusd that will follow the full D-Bus
specification, but it nicely suited for an embedded Linux system and you
will love it. It will talk the same protocol and so Upstart and all the
users don't really care.

Since I have been through most of these steps already, in some cases you
will ask yourself what the f*ck is this. Simple go with it. The D-Bus
specification and protocol are stable and the D-Bus community tries to
be fully backward compatible. The first issue you will run into is the
authentication step between the client and the bus. It is braindead, but
simply see it as part of the protocol.

Regards

Marcel