[Dev] Tizen 3 architecture question

Rees, Kevron kevron.m.rees at intel.com
Fri Oct 18 21:50:02 GMT 2013


On Thu, Oct 17, 2013 at 8:54 AM, Gerken, Stephen
<sgerken at jaguarlandrover.com> wrote:
> I wrote an earlier reply which did not go to the mailing list, which reply I
> repeat here.  Sorry for any confusion induced by my error.
>
> Hello Mikko,
>
>
>> I am initially interested in understanding what the external interfaces
>> are that Tizen makes available, and also internal interfaces to the extent
>> that there is an internally segmented structure or component structure by
>> which Tizen may be augmented, with a primary focus on information flow from
>> physical devices to Tizen apps, and on inquiry or command flow from Tizen
>> apps to physical devices.  I recognize that for some peripheral devices, the
>> I/O at the level closest to the device is brokered by a driver which is not
>> part of Tizen; in this case, I am interested in the API that Tizen provides
>> for the author of the driver to interact with Tizen.
>
>
>> To illustrate all this is not a simple task but I have some ideas. Let's
>> see.
>
> I am well aware that I am asking a potentially very large question.  I do
> have a little background within which to ask, which may help scope an
> answer.
>
> I am assuming, at the moment, that Tizen being Linux-derived means that
> Tizen internally uses the everything-is-a-file approach to driver
> interaction.  That is to say, that every externally-mounted electrical
> component appears within Tizen as something in /dev, and i/o between Tizen
> and the relevant driver is via read(), write(), and ioctl().  I am assuming
> further that substantially all exposure of these device interactions to web
> apps is via the "tizen" object as per
> https://developer.tizen.org/help/index.jsp?topic=%2Forg.tizen.gettingstarted%2Fhtml%2Ftizen_overview%2Ftizen_architecture.htm
>
> 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"?
>

This sounds like you want a WRT plugin (see wrt-plugins-tizen or
wrt-plugins-ivi).  Alternatively, what exactly is this electrical
component?  Would it fall under the domain of the Automotive Message
Broker (AMB)?  If so, you can just create an AMB plugin and the
component will be accessible in the already functional tizen.vehicle
namespace automatically via the "vehicle" plugin in wrt-plugins-ivi.

Kevron

> 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.
>
> Thanks much,
>
> Steve Gerken
> -------------------
> Linux Developer
> MSX, as broker for Jaguar Land Rover
>
> One World Trade Center, 121 SW Salmon Street, 11th Floor, Portland, Oregon,
> 97204
> Email: sgerken at jaguarlandrover.com
>
>
>
>
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev
>


More information about the Dev mailing list