diff mbox

[v3,2/9] Split odp_buffer.h into API and platform parts

Message ID 1398246839-15554-3-git-send-email-taras.kondratiuk@linaro.org
State Superseded
Headers show

Commit Message

Taras Kondratiuk April 23, 2014, 9:53 a.m. UTC 
Keep platform specific values in separate header file.

Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
---
 include/odp_buffer.h                             |   15 +--------------
 platform/linux-generic/Makefile                  |    2 ++
 platform/linux-generic/include/plat/odp_buffer.h |   11 +++++++++++
 3 files changed, 14 insertions(+), 14 deletions(-)
 create mode 100644 platform/linux-generic/include/plat/odp_buffer.h

Comments

Savolainen, Petri (NSN - FI/Espoo) April 23, 2014, noon UTC | #1 
Hi,

It would be better to merge TI implementation first with copied files, etc. We could decide on the API re-use strategy after that and implement it with a separate set of patches, if needed.

I'm still not convinced if it's worth the effort to split all the API files. Does potential re-use of function prototypes justify harder to read/understand API structure? A really HW optimized implementation would likely take a copy and re-organize/re-implement the files as it wishes (it's not too many line of code in the headers). Are there vendors that can  afford not to be 100% optimized? 

Function inlines can be overrided (that's good finding), but only if matching linux-generic object files are not re-used. Or would we inline all potentially inline-able functions also there? Or would we ifdef all such functions?

Also there are still a lot of typedefs and defines (potentially HW specific) that need to be copied into /plat/*.h.


-Petri


> -----Original Message-----
> From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp-
> bounces@lists.linaro.org] On Behalf Of ext Taras Kondratiuk
> Sent: Wednesday, April 23, 2014 12:54 PM
> To: lng-odp@lists.linaro.org
> Subject: [lng-odp] [PATCH v3 2/9] Split odp_buffer.h into API and
> platform parts
> 
> Keep platform specific values in separate header file.
> 
> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
> ---
>  include/odp_buffer.h                             |   15 +-------------
> -
>  platform/linux-generic/Makefile                  |    2 ++
>  platform/linux-generic/include/plat/odp_buffer.h |   11 +++++++++++
>  3 files changed, 14 insertions(+), 14 deletions(-)
>  create mode 100644 platform/linux-generic/include/plat/odp_buffer.h
> 
> diff --git a/include/odp_buffer.h b/include/odp_buffer.h
> index 2d2c25a..7e1108c 100644
> --- a/include/odp_buffer.h
> +++ b/include/odp_buffer.h
> @@ -18,21 +18,8 @@
>  extern "C" {
>  #endif
> 
> -
> -
>  #include <odp_std_types.h>
> -
> -
> -
> -
> -
> -/**
> - * ODP buffer
> - */
> -typedef uint32_t odp_buffer_t;
> -
> -#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */
> -
> +#include <plat/odp_buffer.h>
> 
>  /**
>   * Buffer start address
> diff --git a/platform/linux-generic/Makefile b/platform/linux-
> generic/Makefile
> index ec5d4a7..77269a4 100644
> --- a/platform/linux-generic/Makefile
> +++ b/platform/linux-generic/Makefile
> @@ -137,5 +137,7 @@ headers_install: libs
>  	$(ECHO) Installing headers to $(DESTDIR)/include
>  	$(COPY) $(ODP_ROOT)/include $(DESTDIR)
>  	$(COPY) include/api/* $(DESTDIR)/include/
> +	$(MKDIR) $(DESTDIR)/include/plat
> +	$(COPY) include/plat/* $(DESTDIR)/include/plat
> 
>  install: lib_install headers_install
> diff --git a/platform/linux-generic/include/plat/odp_buffer.h
> b/platform/linux-generic/include/plat/odp_buffer.h
> new file mode 100644
> index 0000000..1605324
> --- /dev/null
> +++ b/platform/linux-generic/include/plat/odp_buffer.h
> @@ -0,0 +1,11 @@
> +/*
> + * No protector.
> + * This file should be included only in one corresponding top level
> header.
> + */
> +
> +/**
> + * ODP buffer
> + */
> +typedef uint32_t odp_buffer_t;
> +
> +#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */
> --
> 1.7.9.5
> 
> 
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp
Taras Kondratiuk April 23, 2014, 2:35 p.m. UTC | #2 
On 04/23/2014 03:00 PM, Savolainen, Petri (NSN - FI/Espoo) wrote:
> Hi,
> 
> It would be better to merge TI implementation first with copied files, etc. We could decide on the API re-use strategy after that and implement it with a separate set of patches, if needed.

We need to agree on some approach here.
That's not fun to make U-turn once more.

> I'm still not convinced if it's worth the effort to split all the API files.
> Does potential re-use of function prototypes justify harder to
read/understand API structure?

We can do "lazy splitting". When any new platform need to do some
modification in a header it will split that header.
But I do see value in splitting them all together. include/*.h will
contain only API specification. For example most of macros and typedefs
can be HW specific. Placing them into plat/*.h makes this clear.

> A really HW optimized implementation would likely take a copy and re-organize/re-implement the files as it wishes (it's not too many line of code in the headers). Are there vendors that can  afford not to be 100% optimized? 

Yes header file names are restricted. Is it important limitation?

Do you see any limitation for performance optimizations. As per my
understanding implementation can optimize anything in plat/*.h files.
Sure only if splitting was done correctly and include/*.h don't have
anything platform specific left.

> Function inlines can be overrided (that's good finding), but only if matching linux-generic object files are not re-used. Or would we inline all potentially inline-able functions also there? Or would we ifdef all such functions?

I assume if you want to inline function then there is no way to reuse
linux-generic objects which have the same function. Splitting doesn't
change anything in this case.

> Also there are still a lot of typedefs and defines (potentially HW specific) that need to be copied into /plat/*.h.

Agree. They should all go into plat/*.h
Maxim Uvarov April 23, 2014, 3:22 p.m. UTC | #3 
On 04/23/2014 06:35 PM, Taras Kondratiuk wrote:
>> Also there are still a lot of typedefs and defines (potentially HW specific) that need to be copied into/plat/*.h.
> Agree. They should all go into plat/*.h
I think that it is not show stopper for that patch series and can be 
done in next versions. Are there any objections?

Thanks,
Maxim.
Mike Holmes April 23, 2014, 3:25 p.m. UTC | #4 
I think we should take this patch, and work through  subsequent issues when
Vincents DPDK version lands. At that point we will have three
implementations and an even clearer picture.

Mike


On 23 April 2014 11:22, Maxim Uvarov <maxim.uvarov@linaro.org> wrote:

> On 04/23/2014 06:35 PM, Taras Kondratiuk wrote:
>
>> Also there are still a lot of typedefs and defines (potentially HW
>>> specific) that need to be copied into/plat/*.h.
>>>
>> Agree. They should all go into plat/*.h
>>
> I think that it is not show stopper for that patch series and can be done
> in next versions. Are there any objections?
>
> Thanks,
> Maxim.
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
Rosenboim, Leonid April 23, 2014, 5 p.m. UTC | #5 
In my opinion, someone should take the lead on properly separating the normative API from linux-generic implementation, and do that as soon as possible.
This is true for the API header files as well as the current tests and examples.
I would like to see all headers in main include diorectory to inly define normative APIs, and I would like to see at least one example (even a trivial one) that uses the normative (patform-independent) APIs exclusively.
For sure there will be some issues when merging with SoC platform implementation, but by cleanly making a separation early, those issues will be fewer and effect fewer lines of code.

Just my 2 cents,
- Leo
Bill Fischofer April 23, 2014, 5:14 p.m. UTC | #6 
Agree completely.  The blurring was understandable when we only had one
implementation but with others coming together now it's becoming clearer
what's really common vs. implementation-specific.

Bill


On Wed, Apr 23, 2014 at 12:00 PM, Rosenboim, Leonid <
Leonid.Rosenboim@caviumnetworks.com> wrote:

> In my opinion, someone should take the lead on properly separating the
> normative API from linux-generic implementation, and do that as soon as
> possible.
> This is true for the API header files as well as the current tests and
> examples.
> I would like to see all headers in main include diorectory to inly define
> normative APIs, and I would like to see at least one example (even a
> trivial one) that uses the normative (patform-independent) APIs exclusively.
> For sure there will be some issues when merging with SoC platform
> implementation, but by cleanly making a separation early, those issues will
> be fewer and effect fewer lines of code.
>
> Just my 2 cents,
> - Leo
> ________________________________________
> From: lng-odp-bounces@lists.linaro.org <lng-odp-bounces@lists.linaro.org>
> on behalf of Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com>
> Sent: Wednesday, April 23, 2014 5:00 AM
> To: ext Taras Kondratiuk; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCH v3 2/9] Split odp_buffer.h into API and
> platform  parts
>
> Hi,
>
> It would be better to merge TI implementation first with copied files,
> etc. We could decide on the API re-use strategy after that and implement it
> with a separate set of patches, if needed.
>
> I'm still not convinced if it's worth the effort to split all the API
> files. Does potential re-use of function prototypes justify harder to
> read/understand API structure? A really HW optimized implementation would
> likely take a copy and re-organize/re-implement the files as it wishes
> (it's not too many line of code in the headers). Are there vendors that can
>  afford not to be 100% optimized?
>
> Function inlines can be overrided (that's good finding), but only if
> matching linux-generic object files are not re-used. Or would we inline all
> potentially inline-able functions also there? Or would we ifdef all such
> functions?
>
> Also there are still a lot of typedefs and defines (potentially HW
> specific) that need to be copied into /plat/*.h.
>
>
> -Petri
>
>
> > -----Original Message-----
> > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp-
> > bounces@lists.linaro.org] On Behalf Of ext Taras Kondratiuk
> > Sent: Wednesday, April 23, 2014 12:54 PM
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [PATCH v3 2/9] Split odp_buffer.h into API and
> > platform parts
> >
> > Keep platform specific values in separate header file.
> >
> > Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
> > ---
> >  include/odp_buffer.h                             |   15 +-------------
> > -
> >  platform/linux-generic/Makefile                  |    2 ++
> >  platform/linux-generic/include/plat/odp_buffer.h |   11 +++++++++++
> >  3 files changed, 14 insertions(+), 14 deletions(-)
> >  create mode 100644 platform/linux-generic/include/plat/odp_buffer.h
> >
> > diff --git a/include/odp_buffer.h b/include/odp_buffer.h
> > index 2d2c25a..7e1108c 100644
> > --- a/include/odp_buffer.h
> > +++ b/include/odp_buffer.h
> > @@ -18,21 +18,8 @@
> >  extern "C" {
> >  #endif
> >
> > -
> > -
> >  #include <odp_std_types.h>
> > -
> > -
> > -
> > -
> > -
> > -/**
> > - * ODP buffer
> > - */
> > -typedef uint32_t odp_buffer_t;
> > -
> > -#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */
> > -
> > +#include <plat/odp_buffer.h>
> >
> >  /**
> >   * Buffer start address
> > diff --git a/platform/linux-generic/Makefile b/platform/linux-
> > generic/Makefile
> > index ec5d4a7..77269a4 100644
> > --- a/platform/linux-generic/Makefile
> > +++ b/platform/linux-generic/Makefile
> > @@ -137,5 +137,7 @@ headers_install: libs
> >       $(ECHO) Installing headers to $(DESTDIR)/include
> >       $(COPY) $(ODP_ROOT)/include $(DESTDIR)
> >       $(COPY) include/api/* $(DESTDIR)/include/
> > +     $(MKDIR) $(DESTDIR)/include/plat
> > +     $(COPY) include/plat/* $(DESTDIR)/include/plat
> >
> >  install: lib_install headers_install
> > diff --git a/platform/linux-generic/include/plat/odp_buffer.h
> > b/platform/linux-generic/include/plat/odp_buffer.h
> > new file mode 100644
> > index 0000000..1605324
> > --- /dev/null
> > +++ b/platform/linux-generic/include/plat/odp_buffer.h
> > @@ -0,0 +1,11 @@
> > +/*
> > + * No protector.
> > + * This file should be included only in one corresponding top level
> > header.
> > + */
> > +
> > +/**
> > + * ODP buffer
> > + */
> > +typedef uint32_t odp_buffer_t;
> > +
> > +#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */
> > --
> > 1.7.9.5
> >
> >
> > _______________________________________________
> > lng-odp mailing list
> > lng-odp@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/lng-odp
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
Mike Holmes April 23, 2014, 6:13 p.m. UTC | #7 
We can continue to refine as the need, arises,  but it looks like we are
moving towards wanting something more bounded.
To make this separation happen in LNG we need to define & create blueprints
that get assigned to a sprint and closed.

If I make a rough summary, it looks like we are defining deliverables for
three blueprints (BP)

1.  properly separate the normative API from linux-generic implementation
2.  Ensure there is at least one example that uses the normative
(platform-independent) APIs exclusively.
3.  Split up the tests/examples to accommodate platform specifics

I was thinking this is Architectural in nature and might fit as a new ENG
task under ODP v1.0 Architecture <https://cards.linaro.org/browse/CARD-1175>,
given that the other cards are more feature or platform specific under ODP
v1.0

Do we want to convert this thread into defined work items?

Mike



On 23 April 2014 13:14, Bill Fischofer <bill.fischofer@linaro.org> wrote:

> Agree completely.  The blurring was understandable when we only had one
> implementation but with others coming together now it's becoming clearer
> what's really common vs. implementation-specific.
>
> Bill
>
>
> On Wed, Apr 23, 2014 at 12:00 PM, Rosenboim, Leonid <
> Leonid.Rosenboim@caviumnetworks.com> wrote:
>
>> In my opinion, someone should take the lead on properly separating the
>> normative API from linux-generic implementation, and do that as soon as
>> possible.
>> This is true for the API header files as well as the current tests and
>> examples.
>> I would like to see all headers in main include diorectory to inly define
>> normative APIs, and I would like to see at least one example (even a
>> trivial one) that uses the normative (patform-independent) APIs exclusively.
>> For sure there will be some issues when merging with SoC platform
>> implementation, but by cleanly making a separation early, those issues will
>> be fewer and effect fewer lines of code.
>>
>> Just my 2 cents,
>> - Leo
>> ________________________________________
>> From: lng-odp-bounces@lists.linaro.org <lng-odp-bounces@lists.linaro.org>
>> on behalf of Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com
>> >
>> Sent: Wednesday, April 23, 2014 5:00 AM
>> To: ext Taras Kondratiuk; lng-odp@lists.linaro.org
>> Subject: Re: [lng-odp] [PATCH v3 2/9] Split odp_buffer.h into API and
>> platform  parts
>>
>> Hi,
>>
>> It would be better to merge TI implementation first with copied files,
>> etc. We could decide on the API re-use strategy after that and implement it
>> with a separate set of patches, if needed.
>>
>> I'm still not convinced if it's worth the effort to split all the API
>> files. Does potential re-use of function prototypes justify harder to
>> read/understand API structure? A really HW optimized implementation would
>> likely take a copy and re-organize/re-implement the files as it wishes
>> (it's not too many line of code in the headers). Are there vendors that can
>>  afford not to be 100% optimized?
>>
>> Function inlines can be overrided (that's good finding), but only if
>> matching linux-generic object files are not re-used. Or would we inline all
>> potentially inline-able functions also there? Or would we ifdef all such
>> functions?
>>
>> Also there are still a lot of typedefs and defines (potentially HW
>> specific) that need to be copied into /plat/*.h.
>>
>>
>> -Petri
>>
>>
>> > -----Original Message-----
>> > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp-
>> > bounces@lists.linaro.org] On Behalf Of ext Taras Kondratiuk
>> > Sent: Wednesday, April 23, 2014 12:54 PM
>> > To: lng-odp@lists.linaro.org
>> > Subject: [lng-odp] [PATCH v3 2/9] Split odp_buffer.h into API and
>> > platform parts
>> >
>> > Keep platform specific values in separate header file.
>> >
>> > Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
>> > ---
>> >  include/odp_buffer.h                             |   15 +-------------
>> > -
>> >  platform/linux-generic/Makefile                  |    2 ++
>> >  platform/linux-generic/include/plat/odp_buffer.h |   11 +++++++++++
>> >  3 files changed, 14 insertions(+), 14 deletions(-)
>> >  create mode 100644 platform/linux-generic/include/plat/odp_buffer.h
>> >
>> > diff --git a/include/odp_buffer.h b/include/odp_buffer.h
>> > index 2d2c25a..7e1108c 100644
>> > --- a/include/odp_buffer.h
>> > +++ b/include/odp_buffer.h
>> > @@ -18,21 +18,8 @@
>> >  extern "C" {
>> >  #endif
>> >
>> > -
>> > -
>> >  #include <odp_std_types.h>
>> > -
>> > -
>> > -
>> > -
>> > -
>> > -/**
>> > - * ODP buffer
>> > - */
>> > -typedef uint32_t odp_buffer_t;
>> > -
>> > -#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */
>> > -
>> > +#include <plat/odp_buffer.h>
>> >
>> >  /**
>> >   * Buffer start address
>> > diff --git a/platform/linux-generic/Makefile b/platform/linux-
>> > generic/Makefile
>> > index ec5d4a7..77269a4 100644
>> > --- a/platform/linux-generic/Makefile
>> > +++ b/platform/linux-generic/Makefile
>> > @@ -137,5 +137,7 @@ headers_install: libs
>> >       $(ECHO) Installing headers to $(DESTDIR)/include
>> >       $(COPY) $(ODP_ROOT)/include $(DESTDIR)
>> >       $(COPY) include/api/* $(DESTDIR)/include/
>> > +     $(MKDIR) $(DESTDIR)/include/plat
>> > +     $(COPY) include/plat/* $(DESTDIR)/include/plat
>> >
>> >  install: lib_install headers_install
>> > diff --git a/platform/linux-generic/include/plat/odp_buffer.h
>> > b/platform/linux-generic/include/plat/odp_buffer.h
>> > new file mode 100644
>> > index 0000000..1605324
>> > --- /dev/null
>> > +++ b/platform/linux-generic/include/plat/odp_buffer.h
>> > @@ -0,0 +1,11 @@
>> > +/*
>> > + * No protector.
>> > + * This file should be included only in one corresponding top level
>> > header.
>> > + */
>> > +
>> > +/**
>> > + * ODP buffer
>> > + */
>> > +typedef uint32_t odp_buffer_t;
>> > +
>> > +#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */
>> > --
>> > 1.7.9.5
>> >
>> >
>> > _______________________________________________
>> > lng-odp mailing list
>> > lng-odp@lists.linaro.org
>> > http://lists.linaro.org/mailman/listinfo/lng-odp
>>
>> _______________________________________________
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>
>> _______________________________________________
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
Savolainen, Petri (NSN - FI/Espoo) April 24, 2014, 8:29 a.m. UTC | #8 
Hi,

Basically all definitions (except some specific align macros I'm going to remove) in odp/include are already normative. Names of types/macros/constants and function prototypes are normative. Values are implementation specific. Implementation specific headers (xxx_internal.h) are already in linux-generic/include.

Examples from /include:

typedef uint32_t odp_buffer_t;
        ^^^^^^^^  ^^^^^^^^^^
        specific   normative

#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */
          ^^^^^^^^^^        ^^^^^^^^
           normative          specific

/**
 * Buffer start address
 *
 * @param buf      Buffer handle
 *
 * @return Buffer start address
 */
void *odp_buffer_addr(odp_buffer_t buf);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         normative


static inline int odp_atomic_fetch_add_int(odp_atomic_int_t *ptr, int value)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                          normative
{
	return __sync_fetch_and_add(ptr, value);
}
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   specific


We don't e.g. want to limit values implementations may use e.g. XXX_INVALID == 0 or XXX_PRIO0..7 == 0..7. Some other values may be more natural fit to the underlying HW. Application must not use values found from API, only names.


-Petri 



> -----Original Message-----
> From: ext Rosenboim, Leonid [mailto:Leonid.Rosenboim@caviumnetworks.com]
> Sent: Wednesday, April 23, 2014 8:01 PM
> To: Savolainen, Petri (NSN - FI/Espoo); ext Taras Kondratiuk; lng-
> odp@lists.linaro.org
> Subject: RE: [lng-odp] [PATCH v3 2/9] Split odp_buffer.h into API and
> platform parts
> 
> In my opinion, someone should take the lead on properly separating the
> normative API from linux-generic implementation, and do that as soon as
> possible.
> This is true for the API header files as well as the current tests and
> examples.
> I would like to see all headers in main include diorectory to inly
> define normative APIs, and I would like to see at least one example
> (even a trivial one) that uses the normative (patform-independent) APIs
> exclusively.
> For sure there will be some issues when merging with SoC platform
> implementation, but by cleanly making a separation early, those issues
> will be fewer and effect fewer lines of code.
> 
> Just my 2 cents,
> - Leo
> ________________________________________
> From: lng-odp-bounces@lists.linaro.org <lng-odp-
> bounces@lists.linaro.org> on behalf of Savolainen, Petri (NSN -
> FI/Espoo) <petri.savolainen@nsn.com>
> Sent: Wednesday, April 23, 2014 5:00 AM
> To: ext Taras Kondratiuk; lng-odp@lists.linaro.org
> Subject: Re: [lng-odp] [PATCH v3 2/9] Split odp_buffer.h into API and
> platform  parts
> 
> Hi,
> 
> It would be better to merge TI implementation first with copied files,
> etc. We could decide on the API re-use strategy after that and
> implement it with a separate set of patches, if needed.
> 
> I'm still not convinced if it's worth the effort to split all the API
> files. Does potential re-use of function prototypes justify harder to
> read/understand API structure? A really HW optimized implementation
> would likely take a copy and re-organize/re-implement the files as it
> wishes (it's not too many line of code in the headers). Are there
> vendors that can  afford not to be 100% optimized?
> 
> Function inlines can be overrided (that's good finding), but only if
> matching linux-generic object files are not re-used. Or would we inline
> all potentially inline-able functions also there? Or would we ifdef all
> such functions?
> 
> Also there are still a lot of typedefs and defines (potentially HW
> specific) that need to be copied into /plat/*.h.
> 
> 
> -Petri
> 
> 
> > -----Original Message-----
> > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp-
> > bounces@lists.linaro.org] On Behalf Of ext Taras Kondratiuk
> > Sent: Wednesday, April 23, 2014 12:54 PM
> > To: lng-odp@lists.linaro.org
> > Subject: [lng-odp] [PATCH v3 2/9] Split odp_buffer.h into API and
> > platform parts
> >
> > Keep platform specific values in separate header file.
> >
> > Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
> > ---
> >  include/odp_buffer.h                             |   15 +-----------
> --
> > -
> >  platform/linux-generic/Makefile                  |    2 ++
> >  platform/linux-generic/include/plat/odp_buffer.h |   11 +++++++++++
> >  3 files changed, 14 insertions(+), 14 deletions(-)
> >  create mode 100644 platform/linux-generic/include/plat/odp_buffer.h
> >
> > diff --git a/include/odp_buffer.h b/include/odp_buffer.h
> > index 2d2c25a..7e1108c 100644
> > --- a/include/odp_buffer.h
> > +++ b/include/odp_buffer.h
> > @@ -18,21 +18,8 @@
> >  extern "C" {
> >  #endif
> >
> > -
> > -
> >  #include <odp_std_types.h>
> > -
> > -
> > -
> > -
> > -
> > -/**
> > - * ODP buffer
> > - */
> > -typedef uint32_t odp_buffer_t;
> > -
> > -#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */
> > -
> > +#include <plat/odp_buffer.h>
> >
> >  /**
> >   * Buffer start address
> > diff --git a/platform/linux-generic/Makefile b/platform/linux-
> > generic/Makefile
> > index ec5d4a7..77269a4 100644
> > --- a/platform/linux-generic/Makefile
> > +++ b/platform/linux-generic/Makefile
> > @@ -137,5 +137,7 @@ headers_install: libs
> >       $(ECHO) Installing headers to $(DESTDIR)/include
> >       $(COPY) $(ODP_ROOT)/include $(DESTDIR)
> >       $(COPY) include/api/* $(DESTDIR)/include/
> > +     $(MKDIR) $(DESTDIR)/include/plat
> > +     $(COPY) include/plat/* $(DESTDIR)/include/plat
> >
> >  install: lib_install headers_install
> > diff --git a/platform/linux-generic/include/plat/odp_buffer.h
> > b/platform/linux-generic/include/plat/odp_buffer.h
> > new file mode 100644
> > index 0000000..1605324
> > --- /dev/null
> > +++ b/platform/linux-generic/include/plat/odp_buffer.h
> > @@ -0,0 +1,11 @@
> > +/*
> > + * No protector.
> > + * This file should be included only in one corresponding top level
> > header.
> > + */
> > +
> > +/**
> > + * ODP buffer
> > + */
> > +typedef uint32_t odp_buffer_t;
> > +
> > +#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */
> > --
> > 1.7.9.5
> >
> >
> > _______________________________________________
> > lng-odp mailing list
> > lng-odp@lists.linaro.org
> > http://lists.linaro.org/mailman/listinfo/lng-odp
> 
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp
Taras Kondratiuk April 24, 2014, 8:54 a.m. UTC | #9 
On 04/23/2014 09:13 PM, Mike Holmes wrote:
> We can continue to refine as the need, arises,  but it looks like we are
> moving towards wanting something more bounded.
> To make this separation happen in LNG we need to define & create
> blueprints that get assigned to a sprint and closed.
>
> If I make a rough summary, it looks like we are defining deliverables
> for three blueprints (BP)
>
> 1. properly separate the normative API from linux-generic implementation
> 2.  Ensure there is at least one example that uses the normative
> (platform-independent) APIs exclusively.

I'm a bit confused here. Shouldn't we use *only* normative APIs in
examples? What kind of platform-dependent API we are using now?
Ola Liljedahl April 24, 2014, 10:16 a.m. UTC | #10 
Is there some way to verify that applications don't make unwarranted
assumptions on the ODP definitions? E.g. assuming that an ODP abstract
data type is implemented as a pointer (or as a scalar). Can we use
sparse for that?

On 24 April 2014 10:54, Taras Kondratiuk <taras.kondratiuk@linaro.org> wrote:
> On 04/23/2014 09:13 PM, Mike Holmes wrote:
>>
>> We can continue to refine as the need, arises,  but it looks like we are
>> moving towards wanting something more bounded.
>> To make this separation happen in LNG we need to define & create
>> blueprints that get assigned to a sprint and closed.
>>
>> If I make a rough summary, it looks like we are defining deliverables
>> for three blueprints (BP)
>>
>> 1. properly separate the normative API from linux-generic implementation
>> 2.  Ensure there is at least one example that uses the normative
>> (platform-independent) APIs exclusively.
>
>
> I'm a bit confused here. Shouldn't we use *only* normative APIs in
> examples? What kind of platform-dependent API we are using now?
>
> --
> Taras Kondratiuk
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/lng-odp
diff mbox

Patch

diff --git a/include/odp_buffer.h b/include/odp_buffer.h
index 2d2c25a..7e1108c 100644
--- a/include/odp_buffer.h
+++ b/include/odp_buffer.h
@@ -18,21 +18,8 @@ 
 extern "C" {
 #endif
 
-
-
 #include <odp_std_types.h>
-
-
-
-
-
-/**
- * ODP buffer
- */
-typedef uint32_t odp_buffer_t;
-
-#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */
-
+#include <plat/odp_buffer.h>
 
 /**
  * Buffer start address
diff --git a/platform/linux-generic/Makefile b/platform/linux-generic/Makefile
index ec5d4a7..77269a4 100644
--- a/platform/linux-generic/Makefile
+++ b/platform/linux-generic/Makefile
@@ -137,5 +137,7 @@  headers_install: libs
 	$(ECHO) Installing headers to $(DESTDIR)/include
 	$(COPY) $(ODP_ROOT)/include $(DESTDIR)
 	$(COPY) include/api/* $(DESTDIR)/include/
+	$(MKDIR) $(DESTDIR)/include/plat
+	$(COPY) include/plat/* $(DESTDIR)/include/plat
 
 install: lib_install headers_install
diff --git a/platform/linux-generic/include/plat/odp_buffer.h b/platform/linux-generic/include/plat/odp_buffer.h
new file mode 100644
index 0000000..1605324
--- /dev/null
+++ b/platform/linux-generic/include/plat/odp_buffer.h
@@ -0,0 +1,11 @@ 
+/*
+ * No protector.
+ * This file should be included only in one corresponding top level header.
+ */
+
+/**
+ * ODP buffer
+ */
+typedef uint32_t odp_buffer_t;
+
+#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */