Clarification on upstart-0.5 and dbus usage

[Garrett Cooper]

On Thu, Jun 19, 2008 at 8:42 AM, Marcel Holtmann <marcel at holtmann.org> wrote:
> 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.

Thanks Marcel for the input. I'll sync up with Sarvi and the rest of
the team to see if there's any way we can take a subset of the
protocol and run with it.

We'll be in touch.

Cheers,
-Garrett