Hi, I guess we can move development in the future. For now, my understanding is that OP-TEE is also TrustZone-centric "The optee_os git, contains the source code for the TEE in Linux using the ARM(R) TrustZone(R) technology.”
But of course, if we want to abstract TrustZone we can call it TEE generic driver (even though TEE is tightly coupled with TrustZone as for today)
Best, Javier
On 16 Mar 2015, at 09:47, Pascal Brand pascal.brand@linaro.org wrote:
Hi,
I've just noticed (a little bit late) that https://github.com/TrustZoneGenericDriver/linux https://github.com/TrustZoneGenericDriver/linux has TrustZone in the name, whereas we do not want a TrustZone only driver (the generic driver will not be TrustZone). I think it is ok to use this github as this is just temporary, to help us prototyping, but I just wanted to emphasize this.
Regards, Pascal.
On 16 March 2015 at 07:49, Jens Wiklander <jens.wiklander@linaro.org mailto:jens.wiklander@linaro.org> wrote: Hi Pascal,
On Sat, Mar 14, 2015 at 12:14:27PM +0100, Pascal Brand wrote:
Hello,
There are lots of uint64_t in the proposal, and I wonder how it will behaves on 32bits platforms, in terms of performances, ease to use,...
This interface is not intended to be used directly by client code, instead it's supposed to be wrapped in a client lib. I'm trying to follow the guide lines in https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt https://www.kernel.org/doc/Documentation/ioctl/botching-up-ioctls.txt to avoid the need of having one 64-bit and one 32-bit api.
-- Regards, Jens