Hi all,

From Joakim:
> We should try to avoid code duplication as much as possible. To avoid
> this happening in specific driver we might end up having to leverage the
> specific driver from sub-driver also.
Do you suggest to have another layer, between the "generic" and the "specific"?
If so, it should be in the design from the start because we want 2 backend drivers that target optee: one for TZ, one for our specific copro.

From Joakim:
> I think we can re-use a lot of code in the existing implementation, but
> I also think that we need to move some parts of the code to the specific
> driver (backplane) and maybe also move some parts to user space. So,
Having common parts moved from the driver to the user space is not a problem I guess because they remain common.
Having common parts moved from the generic driver to the specific one is quite odd... apart if we add this new layer.

From the discussion on smc:
> One suggestion I have is also decoupling the platform-specific monitor from the specific driver.
> In my experience this is challenging, but design-wise, if we could have smc handlers for
> different platforms available to different tee-specific implementations, it would be ideal.
> This would also simplify support for some ARMv8 smc calls that need to be issued via pointer access
smc handlers are used to jump to TZ. So such a code should *not* be in the "generic" part.

Regards,
Pascal.



On 6 March 2015 at 09:54, Joakim Bech <joakim.bech@linaro.org> wrote:
Hi Jean-Michel,

On Thu, Mar 05, 2015 at 12:52:52PM +0100, Jean-michel DELORME wrote:
> Hi all,
>
> To continue the discussion and to clarify some points in my mind about
> the objectives to build a common layer or  "generic" driver (GP or
> not) which is a "simple" (should be clarified) way to pass the opaque
> data to a backend without a real added value.
>
> If we keep the proposed modular design (seems the case today), the
> "generic" part can be abstract to manage the notions of context,
> session, command and also shared memory (RPC-like API). This approach
> is compliant with the GP TEEC API or other API which expects to manage
> the remote services.  Basically, based on the well-defined back-end
> call back API (with the mandatory and optional methods), the common
> part will be in-charge to manage the life cycle of the underlying
> managed objects and the back-ends will be and should be a simple
> component to implement the specific part.
>
> Expected service from the back-ends: - power management aspect - inter
> domain memory management (including SHM public management and cache
> management) - firmware manager - communication agent - API
> manipulated interface the manage the opaque data (GP specific aspects
> will be done here)
>
> All these points (design approach) are basically covered by our
> current solution (GP oriented). We need to remove the GP specific
> aspects and to move the tee_supplicant services to the back-end.
>
> You share my view or my vision is completely wrong...
I think we can re-use a lot of code in the existing implementation, but
I also think that we need to move some parts of the code to the specific
driver (backplane) and maybe also move some parts to user space. So,
yes, I think that I in general share your vision.
>
> Br, Jean-Michel
>

--
Regards,
Joakim B

_______________________________________________
Tee-dev mailing list
Tee-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/tee-dev