Clarification on upstart-0.5 and dbus usage

[Scott James Remnant]

On Thu, 2008-06-19 at 00:40 -0700, Saravanan Shanmugham (sarvi) wrote:

> The fact that I still find embedded linux distributions without
> D-Bus. But they all have sockets.
> 
Sockets are a facility for transmitting data.  D-Bus is a protocol for
that data.

You can't just "use sockets" to talk to Upstart, you wouldn't know what
to say.  You need a protocol to be able to address a particular job or
instance, say what you want to do ("start", assumedly) and provide data
to that request.

The same protocol could need to enable you to listen to broadcast
changes on particular job or instances.

We could spend a lot of time and effort writing and maintaining our own
protocol to do this, but that would be large, bloaty and massively
error-prone since IPC is usually the first place you find security
holes.

Instead we use D-Bus; a stable and well-defined protocol that uses Unix
sockets.

> But merely pointing out that there are tonnes of small embedded systems
> out there with their own already chosen communication infrastructure
> that will want to continue to use their own. The cost of moving to D-Bus
> for these system may be prohibitive due to a large existing code basees
> that may be dependent on their existing communication infrastructure. 
> 
Can you give an example of an embedded system that _has_ a communication
infrastructure?

My experience of them suggests that they really don't bother with one,
in fact, they don't even bother with a service manager most of the time
and just use a shell script for /sbin/init!

Since there's not even a service manager yet, what kinds of
communication with Upstart are you actually expecting?

> And 90K lines of code (which is the current size of D-Bus) is a high
> price to pay in these systems just for the sake of talking to Upstart.
> While Upstart itself is just half the size of D-Bus.
> 
Upstart is ~110K lines of code, it's slightly larger than D-Bus.

It's perfectly valid to run Upstart on a system without the D-Bus
daemon; in such a system, Upstart would still start all the jobs marked
"on startup" and any based on their dependencies.

You could still use the "start", "stop" and "status" command-line tools
to manually adjust those jobs.  And if you wanted, you could still use
"telinit", "runlevel" and "shutdown" to affect a SysV-like behaviour.

If that's all you want to do, great.


You would NOT be able to more intimately query and control jobs and
their interfaces from another application, since for that you'd need the
D-Bus daemon to arbitrate your messages.

You would NOT be able to control Upstart from a proprietary application
(I consider running initctl and parsing the output equivalent to dynamic
linking, and thus the GPL would apply to whatever program did that).

And most sadly, you would not be able to start jobs on anything more
complex than "on startup" or when another job is started or stopped.
Since you have no D-Bus daemon, you would also not have HAL and thus
would not have the rich objects, methods and signals that represent the
hardware.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20080619/30a1523e/attachment.pgp