G-P-M on the wrong track?!

[Michael Krivoruchko]

Hi,

The specification is a contract. HAL specification states on the first
line:

   HAL "is a piece of software that provides a view of the various
   hardware attached to a system."

Moreover, a single daemon simply should not have all the privileges
necessary to control all possible type of devices. This is specifically
true on multiuser systems. Therefore, I believe, the daemon should
remain a centralized facility which provides an information about devices
to the desktop applications.

It should be possible to control a device through the functionality
exposed on the system instance of D-Bus by a daemon which is responsible
for the device.

Misha
--

On 16/10/05 12:41, Richard Hughes wrote:
> On Sun, 2005-10-16 at 12:26 +0200, Matthias Grimm wrote:
>> Hi,
>> Richard might not like to hear this but I think the G-P-M development
>> is on the wrong track.
> 
> Criticism is always good. I know I'm enthusiastic but sometimes you need
> to take a step back.
> 
>> It started with the aim to build a GUI for power
>> management features. So far so good. But in the meantime it piles more
>> and more power management functions and because it runs with user
>> privileges and need someone to do the dirty work, clutters HAL with low
>> level power management functions which it is not designed for.
> 
> Hmm, disagree here. HAL is used as a "Hardware Abstraction" daemon.
> 
> For example:
> 
> I want to get a UPS's charge. I search for all the battery objects with
> type "ups"
> 
> I then use hal to get battery.percentage_charge
> 
> I want to get a laptop battery charge. I search for all battery objects
> with type "primary"
> 
> I then use hal to get battery.percentage_charge
> 
> The same with wireless mice and keyboards.
> 
> You see? One abstracted interface using very different information
> stores (serial, acpi, csr).
> 
> Also putting all the ACPI data in HAL has let us fix *many* broken
> BIOS's, so that any userspace application doesn't have to care about the
> specific details. I know its not such an issue for the PMU laptops out
> there, but ACPI is broken more of the time than working.
> 
>> Continuing this path will cause a dilemma for the end user: He has to
>> decide between a well working power management (for example on powerpc
>> machines, see pbbuttons.sourceforge.net) and the gnome desktop, because
>> G-P-M has the GUI he or she likes but the functionallity breaks all
>> other power management concepts (daemons).
> 
> Yes it breaks concepts. It uses DBUS to lock down who can do what, so
> that the default desktop user doesn't have to enter a root password to
> change a hibernation setting.
> 
> I agree HAL support has not great support for powerpc at the moment, but
> the basics are in place.
> 
> See http://gnome-power.sourceforge.net/powerbook.php for why.
> 
>> I would like to suggest a slightly change of project aims:
>>
>> 1. HAL
>> The HAL specifications tells that HAL provides a view and detailed
>> metadata to attached hardware, not more. Not a word about building the
>> mega-system-do-everything daemon.
> 
> Then what's the point in HAL? To provide a nice tree showing our PCI and
> USB hardware? That's looking at HAL without an objective stance, I
> imagine C++ where you can perform a method on an object, the same as
> read it's properties. A lot more powerful than just reading in the
> properties.
> 
> HAL doesn't "do everything" -- it now provides a sane abstraction for
> devices (in my opinion). You can call SetLCDBrightness on a LCD panel
> device, or Suspend on the Computer device, but that's about it for the
> scope of methods.
> 
> The beauty of using HAL addons is that the acpi method is only run for
> acpi systems, the csr addon is only for wireless battery and mouse etc.
> You do not have to start one system service like apmd, or acpid or pmud
> on install, HAL will start the correct addon(s) automatically depending
> on your hardware.
> 
>> Please return to this aim. Limit HAL's functionallity to collect data
>> from various sources and provide it to the desktop for visualisation.
> 
> What's the point? That limits hal to being a flashy version of lspci and
> lsusb when it has *so much more* potential.
> 
>> According to the specification it is not HAL's task to actively control
>> certain hardware or start scripts because of desktop programs wanted so.
> 
> I depends on what you define HAL as. I agree, HAL used to be more of a
> "Hardware Reporting Daemon" and now it's more like true hardware
> abstraction.
> 
> David Zeuthen (HAL maintainer) seemed happy with my changes, and I've
> got no reason to think that he's not okay with the direction HAL has
> taken. (David, speak up if you have!)
> 
>> 2. G-P-M (Desktop Part)
>> The G-P-M project description on gnomefiles.org sais: "The main focus
>> here is the user interface; e.g. allowing configuration of power
>> management from the desktop in a sane way"
> 
> It is sane. No root passwords, no funky permissions files to change and
> no detail about newbie-unfriendly concepts such as ACPI, PMU and APM.
> 
>> This is exactly what G-P-M on the Desktop should do. Visualize data
>> provided by HAL and comunicate with a power management daemon through
>> dbus, but don't perform any power management functions by itself.
> 
> When I was designing g-p-m, I was going down the route that you
> explained. There was a system initscript that launched a daemon that
> spoke to HAL, and the daemon then spoke to g-p-m. This was so complex it
> was never going to work. Speaking to people, it became obvious to me (it
> was spelt out to me!) that this middle daemon was not required at all.
> The policy could be done in g-p-m as a user-session daemon.
> 
> Think about it. How many users do you have logged in to graphical
> desktop environments on your laptop right now? For me it's one, so the
> "session daemon controls the system" idea is valid. On a server with
> multiple user logins, each with a DE, I don't expect to have g-p-m
> installed (or running in each user session), as it's not required. And
> even if it was installed it wouldn't work as the DBUS permissions are
> locked down by default.
> 
> The permission structure is a lot like NetworkManager in this regard.
> 
>> 3. The Power Management Daemon
>> Power management is too critical to lay it in user's hands. It is an
>> important system feature and must be handled by a system daemon running
>> with high privileges. No desktop program is able to fulfil this task.
> 
> Why not? I'm a user, and I want to suspend my laptop after 10 minutes of
> inactivity. Assuming I'm logged in as a console user (i.e. sitting at
> the physical keyboard) I can set this to 10 minutes in g-p-p, and then
> g-p-m will use gnome-screensaver's information about my inactivity so
> that after 10 minutes, g-p-m tells HAL to suspend (hal calls the
> distro-specific scripts) and it "just works".
> 
>> Divide G-P-M in two parts (projects):
>>  part 1: Desktop module which visualize interesting data to the user
>>          including configuration dialogs
>>  part 2: a power management daemon that do the dirty work, provide data
>>          to HAL and receive orders from desktop programs through dbus.
> 
> What "orders" would it take? What data does it provide? As soon as you
> start fleshing out the detail (i.e. formal design) it all gets
> horrendously complex.
> 
>> This concept has a lot of advantages:
>>  - It won't break with existing power management structures. Migration
>>    is possible in small steps,
> 
> Why is that an advantage? On my system now, I can install g-p-m, a
> pretty recent HAL, and (potentially) remove:
> 
> toshutils
> apmd
> acpid
> apmd
> pmud
> ial
> FnFX
> 
> And I can setup most typical actions in g-p-m. The old setups will still
> work, there's nothing *forcing* you to use g-p-m over a custom perl
> script that lives in /etc/acpi/events.d
> 
> Talking to real world users (i.e. proficient with power-management and
> linux) they have intricate scripts written in perl, sh and some C that
> do actions on a hardcoded events (and writing handlers for all their own
> hardware). For a non-power user, /etc/acpi/events.d is a scary place.
> 
>>  - The user can use the Desktop tools with a power manager he likes,
> 
> Same as now. Talking to the KDE guys at LinuxWorld UK (we went out for
> beers afterwards, no blood spilt...) they liked the idea of the HAL
> information store for PM, and said it could be built into the existing
> KDE framework (where they now talk directly to the ACPI and APM
> hardware). They could switch to using HAL to do a suspend in a few lines
> of code (and potentially remove *lots* of system specific code).
> 
>>  - the new power management daemon will cooperate with all desktops,
>>    not only with Gnome,
> 
> HAL does that job now. In KDE4 HAL plays a more prominent role.
> 
>>  - HAL can fulfill its job straight forward. No foreign code anymore.
> 
> Depends on your definition of foreign. If you mean code that is a bit
> different to the standard device stuff, then I think it has actually fit
> in quite well.
> 
>> There are sill a lot of questions to answer but I think this concept is
>> future proof and bring power management on Linux a step forward. There
>> are a lot of good ideas in G-P-M and a lot of highly motivated and
>> entusiastic people push it forward with breathtaking speed
> 
> Urm... You trying to say I should get out more :-) I'm taking that as a
> compliment :-)
> 
>>  but it seems to me that the big plan is incomplete or missing at all.
> 
> There is a plan, but the plan keeps changing :-)
> Like the kernel, if there's found a better way to do something then they
> don't mind changing things (breaking compatibility) and upsetting
> people. Just like the HAL LCD brightness API change.
> 
>> Also everything
>> is eyed through the Gnome spectacles only but power management is not a
>> Gnome only issue.
> 
> Hence using HAL. HAL is cross platform and cross environment.
> 
>> I have developed pbbuttons (power management daemon for Linus on Apple
>> computers) for four years now and I would be pleased to join the team
>> developing the new power management daemon I described above.
> 
> I've seen pbbuttons, and I'm quite impressed. There's lots of code that
> could be used by HAL directly (like the communicating with PMU), without
> the additional overheads of the another management daemon.
> 
> I don't want to be seen as obsoleting pbbuttons with g-p-m, as for
> powermac hardware, pbbuttons is by far generations ahead. The things is,
> pbbuttons is specific to PMU hardware which makes it unsuitable as a
> core GNOME application. If you think as g-p-m as ACPI only (which is
> could be) then the apple user experience is going to be vastly different
> to the ACPI experience. I think we need to unify the many architectures
> into a common entity. Which is why HAL is important.
> 
>> I'm awaiting your feedback.
> 
> Cheers for your email, I hope I've answered some of your questions and
> worries. Sorry for the super long email.
> 
> Richard.
>