On Wed, 9 Jul 2008 13:14:37 -0300 Werner Almesberger <[EMAIL PROTECTED]> babbled:
> Andy Green wrote: > > Carsten's main goal seems as simple as "suspend if you can" and "you > > can't suspend now", something trivial in kernel and perfectly handling > > crashed apps, etc. > > Yeah, Rome wasn't built in a day :-) What I think is important is > to get this started. Once we have the basic infrastructure in place, > even if it's just a skeleton, it will be easy to make it do more. > > That's the difference to "oh, let's hack this into kernel, because > writing something in user space would take a day of work". aye. and that skeleton is. it's in svn: svn co http://svn.openmoko.org/developers/raster/ompower it's a skeleton with just enough meat to "do something useful" which is the minimum requirement for actually having people use it! :) indeed this isnt the end of it, but its a small yet very useful beginning - rome can be built over time. the dbbus api modified and added to. i am not averse to alternate communications mechanisms (eg just raw unix sockets so if u dont want to do dbus complexity from your app you can use sockets instead)... but all in good time. i would expect once screen blanking, backlight and cpu suspend/resume are in good shape i will be adding power controls for other things (gps for starters. splinter currently has some ugly hacks for turning gps on just for itself then off again. being able to have it off by default until a client brings it "online" and it stays online for all gps clients... until no one indicates they want it anymore... we have wifi... bluetooth... etc. etc. > > | That's why I'm so happy about finally getting that user space daemon. > > > > Oh? You plan to write that daemon or even talk to it? Cool. > > Well, it seems that Carsten is writing it, and it also seems that > he and I agree on the basic principles. You can't imagine what > satisfaction I draw from watching people doing what I think is > right, without me having to do it myself ;-) glad to be of serivce master! :) i agree that along the way we will disagree on details and on how to do things and policies etc. and we will sort it out. it's and incredibly small bit of code, so i haven't tried to over-engineer it (yet) and thus it is very very very malleable to pretty much do whatever we need. i wouldn't be surprised that we literally have a whole new policy module per device we do (ompower will need to somehow be able to load such policy modules, or we just literally have a #ifdef and build it per platform), but we'll cross that bridge when we get to it. for now gta01, gta02 and even gta03 could be served by the one ompower codebase easily without #ifdef's or complex module loading. i suspect into the future this can continue for a while... and then maybe FSO will have its world sorted out and be ready to go? maybe FSO will end up changing and adopting the ompower dbus api? i'm not fussed. i just want our phones to work and work well. :) -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
