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