[ohm] Hmm... I have a dull feeling...

[Gross, Mark]

I hope my ramblings aren't too far off the mark.  I'm very new to HAL, gnome and Ohm, but want to get to the point of identifying interface requirements and features needed to make simple, event driven power and thermal policy managers that can be ported from platform to platform that maximizes the reuse of the system level policies, dependencies and constraints associated with modal, power and thermal control of the system.

FWIW I'm a kernel guy starting to look at the user mode code so I could be all wrong.

Comments below....

>-----Original Message-----
>From: ohm-devel-bounces at lists.freedesktop.org [mailto:ohm-devel-bounces at lists.freedesktop.org] On
>Behalf Of Nils Faerber
>Sent: Sunday, April 29, 2007 8:09 AM
>To: Rob Taylor
>Cc: ohm-devel at lists.freedesktop.org
>Subject: Re: [ohm] Hmm... I have a dull feeling...
>
>Rob Taylor schrieb:
>Kimmo Hämäläinen wrote:
>>> On Tue, 2007-04-10 at 20:18 +0200, ext Nils Faerber wrote:
>[...]
>>>> What does that mean?
>>>> That means that the general idea of OHM is good. But the real goal and
>>>> the way to that goal is still too vague to raise interest. The current
>>>> idea, if I got that right, is "to somehow use HAL", to "have some policy
>>>> daemon" with "some plugin interface" and some still quite mysterious
>>>> policy descriptions.
>>>> Also the use cases, though being a nice start, are for my taste a little
>>>> too specific already.
>> Yep. I think the idea of having a system hardware policy manager  with
>> pluggable policy is a useful idea, but atm we don't have enough of an
>> idea of the tasks that it would be involved in to solidify the idea.
>
>OK, then let's ask the people who do know better.
>In my previous mail I mentioned a list of projects that I would be
>willing to contact about their ideas, focus, experience, requirements.

I'm starting to poke around at the notion of event based thermal and power policy managers.  What user / kernel interface requirements fall out of such a thing?  What kernel requirements?  What sysfs naming and interface policy requirements?

>
>What do you think about that list? Any more to add?
>That should hopefully help us then to have a clearer idea of the tasks.
>
>>>> Richard mentioned a very nice example that, in my current understanding,
>>>> does not match the current scheme of OHM very well, the keyboard, or
>>>> more generic, the input method problem.
>>>> This is a very important thing, to switch from hardware buttons, to
>>>> keyboard, to virtual keyboard, and back (or to whatever) - especially on
>>>> a mobile device. You have hardware controls in charge for detecting
>>>> certain conditions, you have the UI involved in presenting or hiding the
>>>> virtual keyboard or softkey areas and at some point a physical keyboard
>>>> like on the Zaurus. How could the policy manager know what the UI is
>>>> capable of? How could you abtract a description for OHM that could match
>>>> all the possible states the hardware can be in and how to match them
>>>> with UI? And if the UI changes, say you invent a radical new input
>>>> method just for one certain UI, how would you integrate this with OHM?
>>>> Would the policy descriptions become UI dependant?
>> Hmm, my take on this is that it isn't really in the domain of OHM. A
>> user app can just inject input events into the kernel and the rest is
>> dealt with as usual from there on. In terms of displaying and hiding the
>> keyboard, a graphical keyboard app can just listen to events from hal
>> for the hardware keyboard being available or hidden. Its probably
>> sensible if we can define a key on the keyboard namespace in hal for
>> hidden/available so this is abstracted.
>
>But it might be the scope of OHM to choose one input method over the other?
>An application requiring an input method should just do that, along with
>possible extra parameters like "numbers only" or "hex only". OHM could
>specify policies in that sense that would choose one method over the
>other, like "no physical keyboard, but touchscreen -> virtual keyboard",
>"physical keyboard and touchscreen -> physical keyboard", etc. In this
>sense this is pretty similar to the backlight example.
>
>[...]
>>> HAL could be replaced with a convenience library. However, this would
>>> still require some standardisation of the device information, similar to
>>> the HAL specification. The library would be able to hide some kernel-
>>> specific conventions behind it and implement this specification, as the
>>> HAL now does. This would be very good for low-RAM devices, because no
>>> daemons would be needed. In short: HAL-like interface implemented
>>> without the HAL daemon or D-Bus daemon.
>> Well, partially HAL exists to sanitise sysfs, but it also exists because
>> not all platforms have a linux sysfs ;) Having said that, I'd love to
>
>Exactly ;)
>We might one day hopefully see OHM on BSD :)
>
>> see a less heavy-weight and more typed way of communicating with
>> kobjects from userland, a lot of the weight of HAL seems to be in
>> talking to sysfs.
>
>Is it really this?
>So a lot of resources is indeed used for text parsers to parse the
>readout of sysfs? That should be optimisable, indeed.
>

Typed interfaces are hard from the perspective of knowledge encapsulation.  On one had you have to have all the knowledge of the hardware within the policy manager anyway, so putting type information into the kernel interface makes for a redundant and dual point (kernel and user mode) maintainenc of information.  I'm thinking a type less usr/kernel interface may be easier.

>>> But in other to implement system-wide policies, some kind of daemon like
>>> OHM would still be needed. Now, I'm not sure why D-Bus would be still
>>> needed... unless OHM needs it to communicate with other daemons and
>>> applications.
>> Yes, fundamentally a policy manager needs to be able to respond to
>> requests from user processes and communicate back to them if requests
>> have been denied. IMO DBus is the right mechanism for this..
>
>Right.
>And in most cases we will have DBus running already. I guess we can
>safely assume systems in the sense of GMAE which will all provide DBus.

We also need the policy manager be event driven.  But, what events?  Polling == bad.

>
>>>> Again, please get me right, I am absolutely in favour of the OHM effort.
>>>> I just would like to ask some nasty questions which came to my mind and
>>>> where I and possibly others struggle to find an answer for or see the
>>>> picture/scheme.
>>>> Maybe by discussing those we get a clearer picture which is more
>>>> attractive to more contributors ;)
>> Discussion is certainly what's needed at this point :)
>
>Good!
>Let's continue this then!
>
>>>> In this sense I would propose to get in closer contact with related
>>>> projects directly, proactively, and ask them which problems they face(d)
>>>> during their development (in the sense of OHM), how they solved them and
>>>> how they would like to see them being solved. For exmaple GPE for sure
>>>> has to say some words about this too, former OPIE and upcoming OPIE-II
>>>> http://opie.home.linuxtogo.org/, OpenMoko, just to name a few.
>> Agreed, also I'm interested in talking to the desktop guys and big-iron
>> server guys. Hardware policy management isn't just a mobile devices problem.
>
>Excellent!
>If you have some specific point you would liek to ask them, maybe from
>your experience with hacking HAL, please let me know!
>I will try to compile some kind of questionnaire which I will send out
>to most of those projects to collect ideas, views, experiences and
>requirements. Asking some good questions would clearly help ;)
>
>[...]
>>>> In an ideal world where every device conforms to kernel-userspace
>>>> interfaces, would we really need HAL in its present form or shape
>>>> anymore? Wouldn't a simple small library with some convenience functions
>>>> be good enough to locate OHM on top of that? Not, why?
>>>> That would be a message we would have to deliver to the kernel folks then.
>> See my above comment on not everything being linux... I don't think its
>
>He ;)
>That will be hard to convince the Linux-kernel people of, but anyway it
>is a good point for OHM development.

I wouldn't make that assumption.

>
>> useful to talk of HAL as independent from DBus, after all DBus was
>> pretty much invented for HAL. I think anything we can do kernel wise to
>> reduce the weight of HAL would be good. I think I need to think a bit on
>> what would be an ideal interface ;)
>
>Do you have any clearer picture you could explain in a few words, what
>causes HAL to be ... um ... big? Is it the parsing? Recursive traversal
>of the sysfs directories? Or what is it more specifically? I am just
>talking about the situation as is, not what it could be. Just a
>description of the problems discovered. Maybe this could even helpthe
>kernel people to change it to the better in some next version.
>
>> For OHM, its plausible that the communication with HAL could be a plugin
>> that'd be replaceable with something that talks straight to sysfs on
>> tighter systems.
>
>Ah, good!
>That sounds like a good compromise.

Small is good.  

>
>>>> As a result I would try to write up a summary in a form of (just a
>>>> thought) a table or similar:
>>>> 	| Problem | Project's solution | Abstract Requirement |
>>>>
>>>> In the end we should have a pretty neat list of requirements that need
>>>> to be addressed. Then we can see how we can map this to HAL, OHM and the
>>>> upper GUI-session layer.

What would the GUI requirements be?  Shouldn't the policy manager be face-less?

--mgross