| Message ID | 1397735782-31924-2-git-send-email-taras.kondratiuk@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
On 2014-04-17 13:56, Taras Kondratiuk wrote: > To be able to make platform specific changes in odp_buffer.h > move it to platform directory. > > Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> > --- > include/odp_buffer.h | 107 ----------------------- Do you really want to terminally delete the central version under include/ ? > platform/linux-generic/include/api/odp_buffer.h | 100 +++++++++++++++++++++ Sorry for being _that guy_, but please extensively motivate this in the commit message, so that we all understand the reasoning why this road is chosen. I have yet to see any motivation why below wont work in the generic header files: PRAGMA_INLINE int api_func(PRAGMA_XXX int a, PRAGMA_YYY int b) where PRAGMA_* are defined in the architecture dependent files. Br, David
David, That looks like a promising approach. I'll sync up with you on this. Thanks. Bill On Thu, Apr 17, 2014 at 9:09 AM, David Nyström <david.c.nystrom@gmail.com>wrote: > On 2014-04-17 13:56, Taras Kondratiuk wrote: > >> To be able to make platform specific changes in odp_buffer.h >> move it to platform directory. >> >> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> >> --- >> include/odp_buffer.h | 107 >> ----------------------- >> > Do you really want to terminally delete the central version under include/ > ? > > platform/linux-generic/include/api/odp_buffer.h | 100 >> +++++++++++++++++++++ >> > > Sorry for being _that guy_, but please extensively motivate this in the > commit message, so that we all understand the reasoning why this road is > chosen. > > I have yet to see any motivation why below wont work in the generic header > files: > > PRAGMA_INLINE int api_func(PRAGMA_XXX int a, PRAGMA_YYY int b) > > where PRAGMA_* are defined in the architecture dependent files. > > Br, > David > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
On 04/17/2014 05:09 PM, David Nyström wrote: > On 2014-04-17 13:56, Taras Kondratiuk wrote: >> To be able to make platform specific changes in odp_buffer.h >> move it to platform directory. >> >> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> >> --- >> include/odp_buffer.h | 107 >> ----------------------- > Do you really want to terminally delete the central version under > include/ ? Well I suppose it should be removed from here if it is moved to platform-specific place. Otherwise implementation will have two headers with the same name in its include search path. >> platform/linux-generic/include/api/odp_buffer.h | 100 >> +++++++++++++++++++++ > > Sorry for being _that guy_, but please extensively motivate this in the > commit message, so that we all understand the reasoning why this road is > chosen. > > I have yet to see any motivation why below wont work in the generic > header files: > > PRAGMA_INLINE int api_func(PRAGMA_XXX int a, PRAGMA_YYY int b) > > where PRAGMA_* are defined in the architecture dependent files. I'm not sure that it will work as it should. Let me try it.
On 17 April 2014 10:45, Taras Kondratiuk <taras.kondratiuk@linaro.org>wrote: > On 04/17/2014 05:09 PM, David Nyström wrote: > >> On 2014-04-17 13:56, Taras Kondratiuk wrote: >> >>> To be able to make platform specific changes in odp_buffer.h >>> move it to platform directory. >>> >>> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> >>> --- >>> include/odp_buffer.h | 107 >>> ----------------------- >>> >> Do you really want to terminally delete the central version under >> include/ ? >> > > Well I suppose it should be removed from here if it is moved to > platform-specific place. Otherwise implementation will have two > headers with the same name in its include search path. VPATH in a makefile will find a local one first, does that help ? > > > platform/linux-generic/include/api/odp_buffer.h | 100 >>> +++++++++++++++++++++ >>> >> >> Sorry for being _that guy_, but please extensively motivate this in the >> commit message, so that we all understand the reasoning why this road is >> chosen. >> >> I have yet to see any motivation why below wont work in the generic >> header files: >> >> PRAGMA_INLINE int api_func(PRAGMA_XXX int a, PRAGMA_YYY int b) >> >> where PRAGMA_* are defined in the architecture dependent files. >> > > I'm not sure that it will work as it should. Let me try it. > > -- > Taras Kondratiuk > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
On 04/17/2014 05:51 PM, Mike Holmes wrote: > On 17 April 2014 10:45, Taras Kondratiuk <taras.kondratiuk@linaro.org > <mailto:taras.kondratiuk@linaro.org>> wrote: > > On 04/17/2014 05:09 PM, David Nyström wrote: > Do you really want to terminally delete the central version under > include/ ? > > > Well I suppose it should be removed from here if it is moved to > platform-specific place. Otherwise implementation will have two > headers with the same name in its include search path. > > VPATH in a makefile will find a local one first, does that help ? Reading about VPATH. Thanks.
On Thu, Apr 17, 2014 at 03:45:35PM +0100, Taras Kondratiuk wrote: > On 04/17/2014 05:09 PM, David Nyström wrote: > > On 2014-04-17 13:56, Taras Kondratiuk wrote: > >> To be able to make platform specific changes in odp_buffer.h > >> move it to platform directory. > >> > >> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> > >> --- > >> include/odp_buffer.h | 107 > >> ----------------------- > > Do you really want to terminally delete the central version under > > include/ ? > > Well I suppose it should be removed from here if it is moved to > platform-specific place. Otherwise implementation will have two > headers with the same name in its include search path. > > >> platform/linux-generic/include/api/odp_buffer.h | 100 > >> +++++++++++++++++++++ > > > > Sorry for being _that guy_, but please extensively motivate this in the > > commit message, so that we all understand the reasoning why this road is > > chosen. > > > > I have yet to see any motivation why below wont work in the generic > > header files: > > > > PRAGMA_INLINE int api_func(PRAGMA_XXX int a, PRAGMA_YYY int b) > > > > where PRAGMA_* are defined in the architecture dependent files. > > I'm not sure that it will work as it should. Let me try it. > Hrm, I can't see how that helps. It doesn't allow you to replace the generic implementation with an inlined platform specific one.
On 2014-04-17 17:34, Stuart Haslam wrote: > On Thu, Apr 17, 2014 at 03:45:35PM +0100, Taras Kondratiuk wrote: >> On 04/17/2014 05:09 PM, David Nyström wrote: >>> On 2014-04-17 13:56, Taras Kondratiuk wrote: >>>> To be able to make platform specific changes in odp_buffer.h >>>> move it to platform directory. >>>> >>>> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> >>>> --- >>>> include/odp_buffer.h | 107 >>>> ----------------------- >>> Do you really want to terminally delete the central version under >>> include/ ? >> >> Well I suppose it should be removed from here if it is moved to >> platform-specific place. Otherwise implementation will have two >> headers with the same name in its include search path. >> >>>> platform/linux-generic/include/api/odp_buffer.h | 100 >>>> +++++++++++++++++++++ >>> >>> Sorry for being _that guy_, but please extensively motivate this in the >>> commit message, so that we all understand the reasoning why this road is >>> chosen. >>> >>> I have yet to see any motivation why below wont work in the generic >>> header files: >>> >>> PRAGMA_INLINE int api_func(PRAGMA_XXX int a, PRAGMA_YYY int b) >>> >>> where PRAGMA_* are defined in the architecture dependent files. >> >> I'm not sure that it will work as it should. Let me try it. >> > > Hrm, I can't see how that helps. It doesn't allow you to replace the > generic implementation with an inlined platform specific one. > I don't fully understand your comment. PRAGMA_INLINE is #defined by the platform specific header file, thus the platform will select pragmas for the user facing API. Perhaps it would help the discussion if you sent a code-sample, which would be hard/impossible to abstract. Br, David
On Thu, Apr 17, 2014 at 04:42:26PM +0100, David Nyström wrote: > On 2014-04-17 17:34, Stuart Haslam wrote: > > On Thu, Apr 17, 2014 at 03:45:35PM +0100, Taras Kondratiuk wrote: > >> On 04/17/2014 05:09 PM, David Nyström wrote: > >>> On 2014-04-17 13:56, Taras Kondratiuk wrote: > >>>> To be able to make platform specific changes in odp_buffer.h > >>>> move it to platform directory. > >>>> > >>>> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> > >>>> --- > >>>> include/odp_buffer.h | 107 > >>>> ----------------------- > >>> Do you really want to terminally delete the central version under > >>> include/ ? > >> > >> Well I suppose it should be removed from here if it is moved to > >> platform-specific place. Otherwise implementation will have two > >> headers with the same name in its include search path. > >> > >>>> platform/linux-generic/include/api/odp_buffer.h | 100 > >>>> +++++++++++++++++++++ > >>> > >>> Sorry for being _that guy_, but please extensively motivate this in the > >>> commit message, so that we all understand the reasoning why this road is > >>> chosen. > >>> > >>> I have yet to see any motivation why below wont work in the generic > >>> header files: > >>> > >>> PRAGMA_INLINE int api_func(PRAGMA_XXX int a, PRAGMA_YYY int b) > >>> > >>> where PRAGMA_* are defined in the architecture dependent files. > >> > >> I'm not sure that it will work as it should. Let me try it. > >> > > > > Hrm, I can't see how that helps. It doesn't allow you to replace the > > generic implementation with an inlined platform specific one. > > > > I don't fully understand your comment. > PRAGMA_INLINE is #defined by the platform specific header file, thus the > platform will select pragmas for the user facing API. > > Perhaps it would help the discussion if you sent a code-sample, which > would be hard/impossible to abstract. > I was thinking in terms of a generic solution to the problem we discussed on the call, rather than anything specific to this change, so perhaps we were thinking of solutions to different problems. It looks like PRAGMA_INLINE as you suggested would allow control over whether the function is qualified as inline or not on a per-platform basis but wouldn't allow for completely replacing the implementation of the function. For example, in include/odp_atomic.h there's static inline uint32_t odp_atomic_fetch_add_u32(odp_atomic_u32_t *ptr, uint32_t value) { return __sync_fetch_and_add(ptr, value); } but under platform/linux-keystone2 you might want to implement it in asm. The prototype would be identical but the implementation different, they both need to be in headers to be inlined correctly, and at build time you need to select which one to use (while ideally avoiding copy-paste and still being able to use other generic implementations from include/odp_atomic.h).
It seems what we really want is to control the precedence of the include paths. So the search order for includes should be odp/platform/<platformname>/include followed by odp/include. That way if there's an odp_atomic.h in platform/include that has an inline expansion appropriate for that platform it will be used and the "base" include directly will only be searched if the platform/include doesn't override it. Bill On Thu, Apr 17, 2014 at 1:04 PM, Stuart Haslam <stuart.haslam@arm.com>wrote: > On Thu, Apr 17, 2014 at 04:42:26PM +0100, David Nyström wrote: > > On 2014-04-17 17:34, Stuart Haslam wrote: > > > On Thu, Apr 17, 2014 at 03:45:35PM +0100, Taras Kondratiuk wrote: > > >> On 04/17/2014 05:09 PM, David Nyström wrote: > > >>> On 2014-04-17 13:56, Taras Kondratiuk wrote: > > >>>> To be able to make platform specific changes in odp_buffer.h > > >>>> move it to platform directory. > > >>>> > > >>>> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> > > >>>> --- > > >>>> include/odp_buffer.h | 107 > > >>>> ----------------------- > > >>> Do you really want to terminally delete the central version under > > >>> include/ ? > > >> > > >> Well I suppose it should be removed from here if it is moved to > > >> platform-specific place. Otherwise implementation will have two > > >> headers with the same name in its include search path. > > >> > > >>>> platform/linux-generic/include/api/odp_buffer.h | 100 > > >>>> +++++++++++++++++++++ > > >>> > > >>> Sorry for being _that guy_, but please extensively motivate this in > the > > >>> commit message, so that we all understand the reasoning why this > road is > > >>> chosen. > > >>> > > >>> I have yet to see any motivation why below wont work in the generic > > >>> header files: > > >>> > > >>> PRAGMA_INLINE int api_func(PRAGMA_XXX int a, PRAGMA_YYY int b) > > >>> > > >>> where PRAGMA_* are defined in the architecture dependent files. > > >> > > >> I'm not sure that it will work as it should. Let me try it. > > >> > > > > > > Hrm, I can't see how that helps. It doesn't allow you to replace the > > > generic implementation with an inlined platform specific one. > > > > > > > I don't fully understand your comment. > > PRAGMA_INLINE is #defined by the platform specific header file, thus the > > platform will select pragmas for the user facing API. > > > > Perhaps it would help the discussion if you sent a code-sample, which > > would be hard/impossible to abstract. > > > > I was thinking in terms of a generic solution to the problem we > discussed on the call, rather than anything specific to this change, > so perhaps we were thinking of solutions to different problems. > > It looks like PRAGMA_INLINE as you suggested would allow control over > whether the function is qualified as inline or not on a per-platform > basis but wouldn't allow for completely replacing the implementation of > the function. For example, in include/odp_atomic.h there's > > static inline uint32_t odp_atomic_fetch_add_u32(odp_atomic_u32_t *ptr, > uint32_t value) > { > return __sync_fetch_and_add(ptr, value); > } > > but under platform/linux-keystone2 you might want to implement it in asm. > > The prototype would be identical but the implementation different, they > both need to be in headers to be inlined correctly, and at build time > you need to select which one to use (while ideally avoiding copy-paste > and still being able to use other generic implementations from > include/odp_atomic.h). > > -- > Stuart. > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
The value of the make variable VPATH specifies a list of directories that make should search. Most often, the directories are expected to contain prerequisite files that are not in the current directory; however, make uses VPATH as a search list for both prerequisites and targets of rules. Thus, if a file that is listed as a target or prerequisite does not exist in the current directory, make searches the directories listed in VPATH for a file with that name. If a file is found in one of them, that file may become the prerequisite (see below). Rules may then specify the names of files in the prerequisite list as if they all existed in the current directory. See Writing Recipes with Directory Search<https://www.gnu.org/software/make/manual/html_node/Recipes_002fSearch.html#Recipes_002fSearch> . In the VPATH variable, directory names are separated by colons or blanks. The order in which directories are listed is the order followed by make in its search. (On MS-DOS and MS-Windows, semi-colons are used as separators of directory names in VPATH, since the colon can be used in the pathname itself, after the drive letter.) On 17 April 2014 14:28, Bill Fischofer <bill.fischofer@linaro.org> wrote: > It seems what we really want is to control the precedence of the include > paths. So the search order for includes should be > odp/platform/<platformname>/include followed by odp/include. That way if > there's an odp_atomic.h in platform/include that has an inline expansion > appropriate for that platform it will be used and the "base" include > directly will only be searched if the platform/include doesn't override it. > > Bill > > > On Thu, Apr 17, 2014 at 1:04 PM, Stuart Haslam <stuart.haslam@arm.com>wrote: > >> On Thu, Apr 17, 2014 at 04:42:26PM +0100, David Nyström wrote: >> > On 2014-04-17 17:34, Stuart Haslam wrote: >> > > On Thu, Apr 17, 2014 at 03:45:35PM +0100, Taras Kondratiuk wrote: >> > >> On 04/17/2014 05:09 PM, David Nyström wrote: >> > >>> On 2014-04-17 13:56, Taras Kondratiuk wrote: >> > >>>> To be able to make platform specific changes in odp_buffer.h >> > >>>> move it to platform directory. >> > >>>> >> > >>>> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> >> > >>>> --- >> > >>>> include/odp_buffer.h | 107 >> > >>>> ----------------------- >> > >>> Do you really want to terminally delete the central version under >> > >>> include/ ? >> > >> >> > >> Well I suppose it should be removed from here if it is moved to >> > >> platform-specific place. Otherwise implementation will have two >> > >> headers with the same name in its include search path. >> > >> >> > >>>> platform/linux-generic/include/api/odp_buffer.h | 100 >> > >>>> +++++++++++++++++++++ >> > >>> >> > >>> Sorry for being _that guy_, but please extensively motivate this in >> the >> > >>> commit message, so that we all understand the reasoning why this >> road is >> > >>> chosen. >> > >>> >> > >>> I have yet to see any motivation why below wont work in the generic >> > >>> header files: >> > >>> >> > >>> PRAGMA_INLINE int api_func(PRAGMA_XXX int a, PRAGMA_YYY int b) >> > >>> >> > >>> where PRAGMA_* are defined in the architecture dependent files. >> > >> >> > >> I'm not sure that it will work as it should. Let me try it. >> > >> >> > > >> > > Hrm, I can't see how that helps. It doesn't allow you to replace the >> > > generic implementation with an inlined platform specific one. >> > > >> > >> > I don't fully understand your comment. >> > PRAGMA_INLINE is #defined by the platform specific header file, thus the >> > platform will select pragmas for the user facing API. >> > >> > Perhaps it would help the discussion if you sent a code-sample, which >> > would be hard/impossible to abstract. >> > >> >> I was thinking in terms of a generic solution to the problem we >> discussed on the call, rather than anything specific to this change, >> so perhaps we were thinking of solutions to different problems. >> >> It looks like PRAGMA_INLINE as you suggested would allow control over >> whether the function is qualified as inline or not on a per-platform >> basis but wouldn't allow for completely replacing the implementation of >> the function. For example, in include/odp_atomic.h there's >> >> static inline uint32_t odp_atomic_fetch_add_u32(odp_atomic_u32_t *ptr, >> uint32_t value) >> { >> return __sync_fetch_and_add(ptr, value); >> } >> >> but under platform/linux-keystone2 you might want to implement it in asm. >> >> The prototype would be identical but the implementation different, they >> both need to be in headers to be inlined correctly, and at build time >> you need to select which one to use (while ideally avoiding copy-paste >> and still being able to use other generic implementations from >> include/odp_atomic.h). >> >> -- >> Stuart. >> >> >> _______________________________________________ >> 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 > >
On 2014-04-17 20:04, Stuart Haslam wrote: > On Thu, Apr 17, 2014 at 04:42:26PM +0100, David Nyström wrote: >> On 2014-04-17 17:34, Stuart Haslam wrote: >>> On Thu, Apr 17, 2014 at 03:45:35PM +0100, Taras Kondratiuk wrote: >>>> On 04/17/2014 05:09 PM, David Nyström wrote: >>>>> On 2014-04-17 13:56, Taras Kondratiuk wrote: >>>>>> To be able to make platform specific changes in odp_buffer.h >>>>>> move it to platform directory. >>>>>> >>>>>> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> >>>>>> --- >>>>>> include/odp_buffer.h | 107 >>>>>> ----------------------- >>>>> Do you really want to terminally delete the central version under >>>>> include/ ? >>>> Well I suppose it should be removed from here if it is moved to >>>> platform-specific place. Otherwise implementation will have two >>>> headers with the same name in its include search path. >>>> >>>>>> platform/linux-generic/include/api/odp_buffer.h | 100 >>>>>> +++++++++++++++++++++ >>>>> Sorry for being _that guy_, but please extensively motivate this in the >>>>> commit message, so that we all understand the reasoning why this road is >>>>> chosen. >>>>> >>>>> I have yet to see any motivation why below wont work in the generic >>>>> header files: >>>>> >>>>> PRAGMA_INLINE int api_func(PRAGMA_XXX int a, PRAGMA_YYY int b) >>>>> >>>>> where PRAGMA_* are defined in the architecture dependent files. >>>> I'm not sure that it will work as it should. Let me try it. >>>> >>> Hrm, I can't see how that helps. It doesn't allow you to replace the >>> generic implementation with an inlined platform specific one. >>> >> I don't fully understand your comment. >> PRAGMA_INLINE is #defined by the platform specific header file, thus the >> platform will select pragmas for the user facing API. >> >> Perhaps it would help the discussion if you sent a code-sample, which >> would be hard/impossible to abstract. >> > I was thinking in terms of a generic solution to the problem we > discussed on the call, rather than anything specific to this change, > so perhaps we were thinking of solutions to different problems. > > It looks like PRAGMA_INLINE as you suggested would allow control over > whether the function is qualified as inline or not on a per-platform > basis but wouldn't allow for completely replacing the implementation of > the function. For example, in include/odp_atomic.h there's > > static inline uint32_t odp_atomic_fetch_add_u32(odp_atomic_u32_t *ptr, > uint32_t value) > { > return __sync_fetch_and_add(ptr, value); > } > > but under platform/linux-keystone2 you might want to implement it in asm. > > The prototype would be identical but the implementation different, they > both need to be in headers to be inlined correctly, and at build time > you need to select which one to use (while ideally avoiding copy-paste > and still being able to use other generic implementations from > include/odp_atomic.h). > So to summarize, the abomination[1] above is introduced due to usage of a compiler missing -flto. And some participants are not willing to upgrade their compilers ? Is this a correct understanding on the "why" part ? Is it introduced since we want to be c99 compliant ? Please state this in the commit message. [1] Function implementation in an API header file
diff --git a/include/odp_buffer.h b/include/odp_buffer.h deleted file mode 100644 index 2d2c25a..0000000 --- a/include/odp_buffer.h +++ /dev/null @@ -1,107 +0,0 @@ -/* Copyright (c) 2013, Linaro Limited - * All rights reserved. - * - * SPDX-License-Identifier: BSD-3-Clause - */ - - -/** - * @file - * - * ODP buffer descriptor - */ - -#ifndef ODP_BUFFER_H_ -#define ODP_BUFFER_H_ - -#ifdef __cplusplus -extern "C" { -#endif - - - -#include <odp_std_types.h> - - - - - -/** - * ODP buffer - */ -typedef uint32_t odp_buffer_t; - -#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */ - - -/** - * Buffer start address - * - * @param buf Buffer handle - * - * @return Buffer start address - */ -void *odp_buffer_addr(odp_buffer_t buf); - -/** - * Buffer maximum data size - * - * @param buf Buffer handle - * - * @return Buffer maximum data size - */ -size_t odp_buffer_size(odp_buffer_t buf); - -/** - * Buffer type - * - * @param buf Buffer handle - * - * @return Buffer type - */ -int odp_buffer_type(odp_buffer_t buf); - -#define ODP_BUFFER_TYPE_INVALID (-1) /**< Buffer type invalid */ -#define ODP_BUFFER_TYPE_RAW 0 /**< Raw buffer */ -#define ODP_BUFFER_TYPE_PACKET 1 /**< Packet buffer */ -#define ODP_BUFFER_TYPE_TIMER 2 /**< Timer buffer */ - -/** - * Tests if buffer is part of a scatter/gather list - * - * @param buf Buffer handle - * - * @return 1 if belongs to a scatter list, otherwise 0 - */ -int odp_buffer_is_scatter(odp_buffer_t buf); - -/** - * Tests if buffer is valid - * - * @param buf Buffer handle - * - * @return 1 if valid, otherwise 0 - */ -int odp_buffer_is_valid(odp_buffer_t buf); - -/** - * Print buffer metadata to STDOUT - * - * @param buf Buffer handle - * - */ -void odp_buffer_print(odp_buffer_t buf); - - -#ifdef __cplusplus -} -#endif - -#endif - - - - - - - diff --git a/platform/linux-generic/include/api/odp_buffer.h b/platform/linux-generic/include/api/odp_buffer.h new file mode 100644 index 0000000..d79e76d --- /dev/null +++ b/platform/linux-generic/include/api/odp_buffer.h @@ -0,0 +1,100 @@ +/* Copyright (c) 2013, Linaro Limited + * All rights reserved. + * + * SPDX-License-Identifier: BSD-3-Clause + */ + + +/** + * @file + * + * ODP buffer descriptor + */ + +#ifndef ODP_BUFFER_H_ +#define ODP_BUFFER_H_ + +#ifdef __cplusplus +extern "C" { +#endif + + + +#include <odp_std_types.h> + + + + + +/** + * ODP buffer + */ +typedef uint32_t odp_buffer_t; + +#define ODP_BUFFER_INVALID (0xffffffff) /**< Invalid buffer */ + + +/** + * Buffer start address + * + * @param buf Buffer handle + * + * @return Buffer start address + */ +void *odp_buffer_addr(odp_buffer_t buf); + +/** + * Buffer maximum data size + * + * @param buf Buffer handle + * + * @return Buffer maximum data size + */ +size_t odp_buffer_size(odp_buffer_t buf); + +/** + * Buffer type + * + * @param buf Buffer handle + * + * @return Buffer type + */ +int odp_buffer_type(odp_buffer_t buf); + +#define ODP_BUFFER_TYPE_INVALID (-1) /**< Buffer type invalid */ +#define ODP_BUFFER_TYPE_RAW 0 /**< Raw buffer */ +#define ODP_BUFFER_TYPE_PACKET 1 /**< Packet buffer */ +#define ODP_BUFFER_TYPE_TIMER 2 /**< Timer buffer */ + +/** + * Tests if buffer is part of a scatter/gather list + * + * @param buf Buffer handle + * + * @return 1 if belongs to a scatter list, otherwise 0 + */ +int odp_buffer_is_scatter(odp_buffer_t buf); + +/** + * Tests if buffer is valid + * + * @param buf Buffer handle + * + * @return 1 if valid, otherwise 0 + */ +int odp_buffer_is_valid(odp_buffer_t buf); + +/** + * Print buffer metadata to STDOUT + * + * @param buf Buffer handle + * + */ +void odp_buffer_print(odp_buffer_t buf); + + +#ifdef __cplusplus +} +#endif + +#endif
To be able to make platform specific changes in odp_buffer.h move it to platform directory. Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> --- include/odp_buffer.h | 107 ----------------------- platform/linux-generic/include/api/odp_buffer.h | 100 +++++++++++++++++++++ 2 files changed, 100 insertions(+), 107 deletions(-) delete mode 100644 include/odp_buffer.h create mode 100644 platform/linux-generic/include/api/odp_buffer.h