Re: [Utopia] app/device event sharing/locking use-case

["C. Gatzemeier" <c gatzemeier tu-bs de>]

Hi,

Am Wednesday 19 October 2005 15:40 schrieb Jeffrey Stedfast:
> I fixed this in CVS a week or 2 ago in a different way

Thanks, I now found running_on_console it in g-v-m.

I have some questions.

I guess what I don't understand yet is this in the hal spec:
>Note that several desktop sessions may be active on the same system; it is 
>the responsibility of session-level software to arbitrate the device access 
>between sessions.

Hal is not concerned with device access policy, but where ist the right place 
for meta policy? Can this really be left to the session-level volume- or more 
general hardware-, or device-mangager?

The place that I thought would know for sure about multiple sessions running 
volume- or device-managers, or a hal aware CD-burnig app etc. would be hald. 
Hmm, so hald should be able to grant some kind of locks I thought. Not locks 
on any real device, merely  potential devices that might be inserted, 
"pre-locks" or exclusive update notifications I guess.


Let's see how far I've understood your logic for simultanious users and how 
far mine goes: :)


If *multiple* logins exist, new *exclusive* use devices (like Partitions, 
smartcard readers,...) should be shown (as icons etc.) to users, but not 
accessed (mounting, starting apps etc.) automaticly.


On a lower level it's probably better to base it on (notification) requests 
rather than on the number of logins.

So there could be a rule for session level apps that automatic access actions 
shall only be executed upon events for which exclusive notification has been 
successfuly requested before.

(Well, getting the info.locked.dbus_service registered might be sufficient. 
From the spec though, that seemed to me as meant only as an informal 
property, only representing real device locking.)

Exclusive notifications (or hal-level pre-locking) could be granted by 
default, as long as there are only single requests. Upon a second request for 
the same device type, the existing exclusive notification could be withdrawn, 
and the new exlusive notification requests denied, or better granted for only 
a limited time.


That would be the event sharing part and what user applications would be 
concerned with.

The device access and locking part would concern hardware subsystems or policy 
wrappers like pmount.

HAL aware policy wrappers (like pmount, or a hal enabled alsa) then allow 
access to already pre-locked devices only to the the app holding the 
hal-lock.

For lockable but currently unlocked devices the policy wraper reqests both a 
hal-lock and the hardware-lock on behalf of the user calling the policy 
wrapper. 

This way legacy apps would still work ok, the only thing they couldn't do is 
pre-locking a device, but that's only something concerning notifications on 
the abstraction layer anyway.

---


Where would checking if a user is on a local console fit in utopia?

Could locking info on the hardware abstraction level be helpful for finer 
grained and unified device access control?
If hal knew about console users it could be possible to have the mic locked on 
the hal-level, and thus with a policy wrapper on the kernel level too, and 
only hand out locks for console users.

Regards,
Christian