Hello Joakim,
What is your proposal to deal with the common code with several specific drivers, and can't stand in generic part ?
Regards Manu
-----Original Message----- From: tee-dev-bounces@lists.linaro.org [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Joakim Bech Sent: vendredi 6 mars 2015 11:24 To: Pascal Brand Cc: tee-dev Subject: Re: [Tee-dev] Interface proposal
Hi Pascal,
On Fri, Mar 06, 2015 at 10:18:48AM +0100, Pascal Brand wrote:
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"?
No, this is not what I suggest, I still think having it in two layers is a good separation. However, in case there is a need to separate the specific driver to support more hardware, TEE's etc, then I think we should leave that up to the one implementing the specific driver.
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.
This is an example where it's up to the specific driver to handle this.
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.
Why is it odd? If parts are generic, they should stay, if they are not generic, then they don't belong there and needs to be moved "somewhere" and "somewhere" is either user space or the specific driver.
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.
+1 regarding SMC not in the generic part, but just as ARM have proposed SMC calling convention it would probably also be good to do the same exercise regards the SMC-calls as we just have started with user space / kernel interface, i.e, what Jens was touching in his response in this mail thread also.
Regards, Pascal.
-- Regards, Joakim B
_______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/tee-dev