FSO resources, GPS-TTFF example (Was: is wifi-driver developed anymore?)

Sebastian Krzyszkowiak seba.dos1 at gmail.com
Sat Aug 15 14:32:35 CEST 2009

On 8/14/09, arne anka <openmoko at ginguppin.de> wrote:
>> If the app doesn't have FSO support, use fsoraw to request the resource.
> _now_ i am confused.
> in my understanding
> - "resources" are an fso concept -- thus, no fso support, no resource
> - fsoraw uses fso calls to utilize the resource -- no resource, no way to
> use fsoraw
>>> why using fsoraw, why isn't fso sufficient?
>>    You are confused. Fsoraw uses FSO.
> sorry, but imo _you_ are confused. i never denied, fsoraw using fso.
> what i always tried to find out, and i understand now even less than
> before: what is the rationale for fsoraw?
> if it does nothing but requesting the resource, a dbus call would do
> exactly the same w/o need of an additional app (and second one to release
> afterwards, of course).
> if it does soemthing a dbus call won't be able to deliver, why isn't fso
> extended to include that functionality?

fsoraw == dbus calls arround starting application. That's you who is
confused here :P

Little C wrapper which do dbus calls is just more practical than bash
script which uses mdbus or dbus-send. And using Request/Release method
isn't possible with dbus-send and mdbus, as they quit just after
calling dbus method, so resource is released immediately after

fsoraw is only small wrapper which do something like
"dbus.call_request_resource(); system('run-app').
dbus.call_release_resource()". Nothing else (maybe except command line
parsing :P). App itself can do exactly the same (and should), but
patching every possible app which can run on Freerunner is insane, so
that's why fsoraw is usable.

Sebastian Krzyszkowiak

More information about the community mailing list