[rfc] The Big Picture

[uwesmail2005-lkml at yahoo.de]

--- David Zeuthen <david at fubar.dk> schrieb:

> 
> Hi,
> 
> Why did you take this off-list? That's normally considered bad form, 
> 
You did. I followed.
> not that I mind in this case though.
> 
> On Oct 27, 2006, at 6:44 AM, uwesmail2005-lkml at yahoo.de wrote:
> > That is why I want one instance that starts programs (and possibly
> has
> > to run as root) and want all other services run as a lesser user.
> 
> Having a generic g_spawn() API isn't all that useful and leads to  
> ignoring real problems.
> 
upstart should not be a generic API (I hope haven' read the spec so
carefully). It should start services, that are defined by .service
files. When it runs as desktop session manager (some use case I briefly
mentioned in the OP) I think it could save some .services in the
session config and so run apps that were open on the desk at the end
of the session.
>   - D-Bus activation is about starting processes on-demand. It's  
> really just a boring implementation detail that buys us that we don't
>  
> have to start something when the system or session starts. E.g.  
> applications can just call into some well-known Name such as  
> org.foo.Printing without worry that it's running. The process can  
> decide to quit when it wants, e.g. when no caller have used it for  
> e.g. 5 minutes. It simplifies application authoring in that respect, 
> 
> apps can simply just assume the Name it wants to use is there. So,  
> there is only one instance running for each Name. Please have a look 
> 
> at D-Bus's bus/activation.c and see why it's actually _hard_ to do  
> this (queuing up D-Bus messages while something is being activated,  
> other stuff).
> 
Yes, I know what activation is. Holding the messages is fine for D-Bus.
But I think it would be better if D-Bus simply emits a message to
upstart (because that is what it does all day) instead of reading a
.service file, spawning a process, possibly from a fork() set aside at
start for this case (User=...) and checking for termination (vs closing
the connection only)
>   - HAL addons (that you wrongly called "user space drivers") are  
> processes launched when certain hardware is attached and does  
> monitoring / polling / can provide service for individual devices.  
> The hardware address is passed in the environment and there is a 1:1 
> 
> relationship between the device and the process launched. E.g. for  
> disks we have one process launched for every actual disk. When a  
> device goes away the process for that device is terminated. That is  
> actually a salient feature, we _want_ one process per device as to  
> avoid interference between them (one example is a bad kernel driver  
> might lock the process polling a disk, we don't want that to take  
> down every addon doing this. This happened a lot during Linux 2.6.9  
> but it's a lot better now yet still happens).
> 
> Notably D-Bus activation on the system message bus takes the  
> "User=<usenamer>" key to run with less privileges. HAL addon's can  
> drop privileges themselves, one common trick is to open a device file
>  
> as root and the drop privileges after that.
> 
Do HAL addons need the hardware address in the Environment? (vs command
line or as already opened device on stdin). I mean can't they be
written
to connect to HAL and get their config there?
> As mentioned before on this list there is considerable overlap  
> between what D-Bus and HAL and upstart is doing. Both wrt starting 	 
> processes and also, doing IPC. I'm not sure why people want upstart  
> to replace D-Bus activation and HAL addons. Both are _different_  
> things (from both standard init features a'la upstart and also from  
> each other) that requires different feature sets (for D-Bus it's  
> queing of messages, for HAL it's things like passing hardware  
> addresses just to name two examples) and (apart from the D-Bus one  
> not working with "User=<username>" until my patches are in), both  
> features have been in resp. D-Bus and HAL for a long time. It's  
> working out pretty well though I admit 3rd party projects could try  
> and use it a bit more, e.g. it would be nice to port e.g. hplip over 
> 
> to run as HAL addons. That shouldn't be hard.
> 
> Note that I, and other D-Bus authors, are also yet to be explained  
> good use cases for Upstart. If you examine the mails on this list  
> about this, you will find that upstart's author agreed that the  
> current spec suffered from christmas-tree decoration whereby  
> enthusiastic people thought it might be useful for instances where  
> you just want D-Bus activation / HAL addons / enforce policy desktop 
> 
> instead. That's why we're worried that all this might lead to just  
> more fragmentation between distributions. I think a lot of this stems
>  
> from ignorance about what D-Bus, HAL and the bigger picture is and to
>  
> a large part this can be blamed on the D-Bus and HAL teams not being 
> 
> good enough about providing roadmaps, probably because we are busy  
> writing code. Maybe it's fixable, I dunno.
> 
In the OP I outlined the bigger Picture as I see it. Including multiple
use cases that involve some thing thats called upstart and is close
enough to upstart as it is now, that upstart could evolve there. If you
don't share this picture, ok. But it is not from ignorance that I have
such a picture.
> Hope this clarifies.
> 
>       David
> 
> 
PS. I'm going on list again with this. Hope it works.


	

	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de