Hi Stephen, On Thu, Oct 17, 2013 at 6:54 PM, Gerken, Stephen < [email protected]> wrote:
> One specific point on which I am unclear is, suppose I have a novel > electrical component "foo" not natively supported by Tizen. Once a driver > is in place and the device appears appropriately in /dev, and once /dev/foo > is mounted elsewhere if appropriate, how does Tizen make device > interactions with this component available at a web app level? Does Tizen > extend its "tizen" object to include the new sub-namespace "tizen.foo"? > What software component exposes "tizen.foo"? What software component > determines the API under "tizen.foo"? > > If you can point me in the right direction within the gbs codebase to find > existing components doing this for existing devices, and let me know a few > relevant filenames or interface API functions, I can start reading code and > see how far I get that way. > Tizen Porting guide [1] will give you hints how the hardware adaptation is handled by various Tizen middleware components. Kevron already gave a good example of AMB plugin architecture and how it enables automotive data passing from hw to a web app via a wrt ivi plugin. Tizen wrt api plugins talk to tizen middleware components (wrt-plugins-tizen). OSP is a similar abstraction for native C++ code. However, OSP is not available for IVI. [1] https://wiki.tizen.org/wiki/Porting_Guide -- Mikko
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
