Tracking users/sessions on the console

[Artem Kachitchkine]

> I read "being system-aware" as it implies a split into two daemons 1) UI
> bits; and 2) system bits much like NetworkManager. Correct?

Yes.

> Btw, do you have comments to what I'm proposing specifically for D-BUS,
> e.g. the ConsoleTracker (instead of the big picture bits though I don't
> mind discussing those)? I'm curious; would this be feasible / easy to
> implement on Solaris too? Do you have something like this already?

Well, I was trying to come up with a use case for ConsoleTracker in 
Solaris and couldn't find a compelling one, so that's why I asked by 
first question.

Power management: Solaris device power management is implemented 
entirely in the kernel. PM settings are system-wide. It is fully 
automatic: the kernel PM daemon detects periods of inactivity and 
attempts to power down leaf devices or even entire branches by calling 
respective driver ops. That worked out pretty well in the past on sparc 
systems, and x86 port is in progress. So there doesn't seem to be a need 
for desktop-specific power management daemon at this time.

Networking: a project was recently started, called Network Auto-Magic 
[1] that is taking a broad look at network configuration in Solaris. 
It's too early to say how would that interact with the desktop, but I'm 
pretty confident the UI will be separate (or even different UIs for 
desktops and servers, who knows).

In terms of volume management, as you know this is still work in 
progress. We haven't quite worked out volume sharing among multiple 
users, but so far our requirements indicate one owner per device is the 
most common case. Assigning devices to users is a separate issue though 
- once we know who owns what, different users' copies of g-v-m should 
not conflict. When noone is logged in on the console, it is assumed all 
devices belong to root, and we'll run a root's copy of the volume 
manager - not g-v-m; a basic, non-GUI, HAL-based volume manager. So 
there isn't a use case for ConsoleTracker here either.

-Artem.

[1] http://www.opensolaris.org/os/community/approachability/nwam/