Hi Igor,
On Thu, 14 Feb 2019 at 17:19, Igor Opaniuk wrote:
>
> Hi Simon,
>
> I've fixed failing test on sandbox_flattree by keeping all defined
> global variables in a driver-private data struct(as you suggested),
> which
> permits to probe multiple tee sandbox devices (sent v5, kept you R-b
>
HI Igor,
On Wed, 13 Feb 2019 at 16:39, Igor Opaniuk wrote:
>
> Hi Simon,
>
> Seems that there is an issue in dm test framework (if understood
> everything correctly),
>
> I've noticed that dm_root is updated when dm tests are being invoked,
> and that's why the new tee udevice is allocated,
Hi Simon,
I've fixed failing test on sandbox_flattree by keeping all defined
global variables in a driver-private data struct(as you suggested),
which
permits to probe multiple tee sandbox devices (sent v5, kept you R-b
tag, please let me know if there are any objections from your side).
But the
Hi Simon,
Seems that there is an issue in dm test framework (if understood
everything correctly),
I've noticed that dm_root is updated when dm tests are being invoked,
and that's why the new tee udevice is allocated, consequently, the
second invocation of probe in tee driver occurs.
In
Hi Igor,
On Tue, 12 Feb 2019 at 14:54, Igor Opaniuk wrote:
>
> Hi Tom, Simon,
>
> So I did a little investigation and found out that, the issue in that
> hcreate_r() invocation in the tee sandbox driver fails because the
> hashtable was allocated before.
> Debugging showed that the sandbox tee
Hi Tom, Simon,
So I did a little investigation and found out that, the issue in that
hcreate_r() invocation in the tee sandbox driver fails because the
hashtable was allocated before.
Debugging showed that the sandbox tee driver is probed twice every
time (although remove() is never called, it's
On Mon, Feb 11, 2019 at 04:59:54PM +0200, Igor Opaniuk wrote:
> Hi Tom,
>
> Thanks for pointing that out.
> I've done a little investigation, and the interesting thing is that it
> never fails when I exclude other tests, for example, running only
> ut_dm subset:
> ./test/py/test.py --bd
Hi Tom,
Thanks for pointing that out.
I've done a little investigation, and the interesting thing is that it
never fails when I exclude other tests, for example, running only
ut_dm subset:
./test/py/test.py --bd sandbox_flattree --build -s -k ut_dm
or even this particular test:
./test/py/test.py
On Sun, Jan 27, 2019 at 04:34:05PM +0200, Igor Opaniuk wrote:
> AVB version 1.1 introduces support for named persistent values
> that must be tamper evident and allows AVB to store arbitrary key-value
> pairs [1].
>
> Introduce implementation of two additional AVB operations
>
9 matches
Mail list logo
