On 25 February 2016 at 22:43, Mike Holmes wrote:
> On 25 February 2016 at 08:17, Christophe Milard <
> christophe.mil...@linaro.org> wrote:
>
>> I guess this is stuck untill BKK discussion...?
>>
>
> I hope not.
>
>
>>
>> On 18 February 2016 at 12:37, Christophe Milard <
>> christophe.mil...@lina
On 25 February 2016 at 08:17, Christophe Milard <
christophe.mil...@linaro.org> wrote:
> I guess this is stuck untill BKK discussion...?
>
I hope not.
>
> On 18 February 2016 at 12:37, Christophe Milard <
> christophe.mil...@linaro.org> wrote:
>
>> A complete -partly working- driver prototype w
I guess this is stuck untill BKK discussion...?
On 18 February 2016 at 12:37, Christophe Milard <
christophe.mil...@linaro.org> wrote:
> A complete -partly working- driver prototype was sent as in RFC:
> https://lists.linaro.org/pipermail/lng-odp/2016-January/019162.html
> This approach of the dr
A complete -partly working- driver prototype was sent as in RFC:
https://lists.linaro.org/pipermail/lng-odp/2016-January/019162.html
This approach of the driver interface "extending" the application interface
was refused and we decided that the driver would have its own separate
definition... in it
I really don't like what we are doing here. We should try to avoid any
code duplication.
Add odpdrv_ prefix to all odp functions and move them to other place is
not thing we should to do.
And also, in my understanding, we should not implement our own
programming language for odp drivers.
So
Signed-off-by: Christophe Milard
---
include/odp/drv/spec/byteorder.h | 176 +++
1 file changed, 176 insertions(+)
create mode 100644 include/odp/drv/spec/byteorder.h
diff --git a/include/odp/drv/spec/byteorder.h b/include/odp/drv/spec/byteorder.h
new file mo
