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

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
dos



More information about the community mailing list