Re: [Utopia] is gmv only ment for mountable stuff?

["John (J5) Palmieri" <johnp redhat com>]

On Tue, 2004-08-03 at 12:58 -0400, Robert Love wrote:
> On Tue, 2004-08-03 at 11:07 -0400, John (J5) Palmieri wrote:
> 
> > I think what we need for the future is something similar to xinet.d for
> > services.  Basically have a single daemon that can efficiently route
> > messages to different policy engines without them having to run as
> > daemons.
> 
> HAL does this now via callouts.
> 
> It works great, but it runs things as root and not as the user.  I like
> the current delineation between system and user-level, so I suppose one
> idea is to add per-(logged in)-user callouts.
> 
> 	Robert Love

My problem with this now is that it spawns a shell for every callout
script in the callout directories.  There is no intelligent routing
going on.  This is great for quick hacks but for the future when DBUS is
pervasive this will become a bottleneck.  Perhaps I should sit down and
write up in detail the idea for a pluggable policy daemon.  It extends
beyond HAL in usefulness.  Basically it eliminates the need to have
separate daemons running for each policy service (whether it be a HAL
policy or just some message coming over DBUS that envokes some sort of
policy).  The policy daemon would route messages to the appropriate
policy engine.  If the engine is not loaded it would be loaded.
Subsequent calls to the policy engine would not need to incur the cost
of startup.  Policy engines that are never used are never loaded and
those which are loaded can be unloaded based on some caching criteria.
An API for persistent storage would allow fast access for state
information.

It is just an idea right now and perhaps there are other ways to solve
the problem but every time the fix for a policy I need to implement is
"create yet another daemon" I cringe.  Per-(logged in)-user callouts
seems like an idea for getting rid of session daemons like g-v-m but how
would it work?

-- 
John (J5) Palmieri
Associate Software Engineer
Desktop Group
Red Hat, Inc.
Blog: http://martianrock.com