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...
Br, Jean-Michel
-----Original Message----- From: tee-dev-bounces@lists.linaro.org [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Valentin Manea Sent: Thursday, March 05, 2015 12:15 PM To: Emmanuel MICHEL; tee-dev Subject: Re: [Tee-dev] Interface proposal
HI Emmanuel, On 05.03.2015 11:37, Emmanuel MICHEL wrote:
Hello Valentine,
Just for me to understand:
" To be more specific the ioctl structure format should be somewhat common."
Today we use GP interface. With which other api do you want to communize the interface ? Thanks
GP is just an API, the binary format is implementation specific. However in the specific case of IOCTLs we are talking about send some binary data from user space to kernel which will forwarded to TEE. Since we are trying to build a common layer I think this should have some comonalities to cover the generic TEEs. I would guess people upstream too would like it more if we didn't just say GP is the only interface.
Valentin
_______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev