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

[Rob Taylor]

Apologies for the lateness of this reply, its been sitting unsent in my
drafts folder for ages...

Nils Faerber wrote:
> 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.
> 
> 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.

The list looks good to me. Like I mentioned before, I'd like to get some
input from big-iron guys, but that's really not my area either. I think
David Weinehall mentioned something about that in the OHM talk at
FOSDEM. David do you have any pointers?

>>>> 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.

Yes, I think you're right, an OHM plugin could well be something that
chooses between attached physical keyboards (think hard keys and a
bluetooth keyboard) and gives a dbus interface for the GUI to ask wether
it should be displaying a virtual keyboard or not.

> [...]
>>> 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 :)

Indeed :D

>> 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.

Well, actually it spends an large amount of its 'coldplug' time in
syscalls, presumably trawling sysfs. I really need to spend some time
detailing exactly how it spent, however.

>>> 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.

Certainly all GMAE systems will be running DBus. I think its also fair
to assume that all gui-based systems will be running DBus.

[snip]

>>>> 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 ;)

IMO, The main question that needs to be asked are:
'What are your current hardware state management tools?'
'What are your current power/thermal management tools?'
'What are the current drawbacks you find?'


> [...]
>>>> 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.
> 
>> 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.


In terms of memory size, thats really HAL's fault - currently each
device gets a 4k alloc all to itself, so if you have 255 virtual ttys,
thats a lot of wasted memory. The solution here is to reengineer HAL's
device storage structures. In terms of startup time, my feeling is that
thats mostly to do with trawling sysfs and/or communicating with udevd,
but I need to do quite a bit more investigation before I point fingers ;)


>> 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.

:)

>>>> 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.
>>> Sounds good. Something like OHM is definitely needed, even if HAL is not
>>> needed :)
>> Sounds good to me too.
> 
> Great!
> I'll draft that up next week then and post it on the list for "public"
> review ;)

Sounds good to me!

Thanks,
Rob Taylor
>> Thanks,
>> Rob Taylor
> 
> Thank you too!
> 
>>> BR; Kimmo
> Cheers
>   nils faerber
>