I think it's better to have these configuration limits in one place than to find them scattered all over. That was why they had ODP_CONFIG_xxx prefixes in the first place.
Perhaps worth discussing in tomorrow's ARCH call, however I don't think we have critical architectural "mass" given the Summer holidays. On Tue, Jul 21, 2015 at 4:27 PM, Mike Holmes <[email protected]> wrote: > > > On 21 July 2015 at 16:54, Bill Fischofer <[email protected]> > wrote: > >> One of the principles of ODP APIs is that they do not unnecessarily >> impose structure on the implementation. So APIs in general do not specify >> or return aggregate information. A static table might seem "efficient" >> however consider an implementation where things like pool counts were >> exposed (by HW) as a special purpose register (SPR) designed to be read. >> Forcing these individual limits into an artificial aggregate would not be >> implementation-friendly. >> >> Implementations can easily adapt the linux-generic files as-is, simply >> replacing the internal #defines with their own values, or else implementing >> the inlined access functions as makes the most sense. As I mentioned, I >> believe the #defines should be deprecated in favor of the APIs for anything >> except internal use. This would simply mean that the tests and examples >> that currently use them for dimensioning arrays would need to do so on a >> dynamic basis. >> >> The idea behind encouraging the use of APIs rather than #defines for this >> sort of information is both for consistency with the rest of ODP, as well >> as to better support future ABI requirements since static #defines are not >> runtime portable. >> > > Aiming at ABI compliance is worthwhile a reason to convert them to > functions. > > However then the notion of a big fat config file loses value for me > because it will become a complected mixture of API calls for un-associated > values, that only made sense if they were compile time defines I think. > > Would it not be better to associate this data with their modules, that is > where you would expect to find these answers and then a common pattern > emerges for the naming also. The current naming does not describe the data > returned in a number of cases. > > /** > * Maximum number of pools > + * @return The maximum number of pools supported by this platform > */ > -#define ODP_CONFIG_POOLS 16 > +int odp_config_pools(void); ------> +int odp_pool_max(void) > > /** > * Maximum number of queues > + * @return The maximum number of queues supported by this platform > */ > -#define ODP_CONFIG_QUEUES 1024 > +int odp_config_queues(void); -------> +int odp_queue_max(void); > > > >> >> On Tue, Jul 21, 2015 at 12:53 PM, Nicolas Morey Chaisemartin < >> [email protected]> wrote: >> >>> >>> >>> >>> Nicolas Morey Chaisemartin KALRAY SA >>> www.kalray.eu >>> Phone : +33 6 42 46 68 87 >>> [email protected] Follow us 86 rue de Paris >>> 91400 Orsay FRANCE >>> 445 rue Lavoisier >>> 38330 Montbonnot FRANCE This message contains information that may be >>> privileged or confidential and is the property of the KALRAY SA. It is >>> intended only for the person to whom it is addressed. If you are not the >>> intended recipient, you are not authorized to print, retain, copy, >>> disseminate, distribute, or use this >>> ----- Mike Holmes <[email protected]> wrote: >>> > On 21 July 2015 at 13:01, Bill Fischofer <[email protected]> >>> wrote: >>> > >>> > > Well, we want to encourage applications to make use of the APIs >>> rather >>> > > than the #defines since that provides a more flexible interface and >>> is more >>> > > consistent with the rest of ODP. I originally thought to rename the >>> > > #defines from ODP_CONFIG_xxx to _ODP_CONFIG_xxx to emphasize that the >>> > > #defines are intended for internal rather than external use, however >>> a >>> > > number of our examples reference them directly for things like array >>> > > dimensioning. >>> > > >>> > > Worth discussing this further. Any others have input to this? >>> > > >>> > >>> > Thinking out loud if we go down this route. >>> > >>> > Given that the new API is essential returning data from a static table >>> of >>> > defines describing the limits of the platform I feel like it should be >>> > defined as a static table by the platform. >>> > I think then the code can be reused as the access functions all become >>> just >>> > indexes into the table defined per platform, it feels like it contains >>> the >>> > differences per platform more cleanly. >>> > >>> >>> I like this idea. Less code to rewrite for other platforms. >>> >>> > >>> > > >>> > > On Tue, Jul 21, 2015 at 11:57 AM, Nicolas Morey-Chaisemartin < >>> > > [email protected]> wrote: >>> > > >>> > >> They currently do not need to edit include/odp/api/config.h. >>> > >> I ran into the issue yesterday and realized that you can override >>> those >>> > >> settings from platform/<name>/include/odp/config.h already. >>> > >> Because users are supposed to include odp/<name>.h which in turn >>> includes >>> > >> odp/api/<name.h>, it is quite simple to override global settings >>> this way. >>> > >> >>> > >> I'm not against this patch although it's a bit of shame that every >>> > >> platform will have to duplicate all the file (including static >>> inline >>> > >> functions) to change the define value. >>> > >> >>> > >> Nicolas >>> > >> >>> > >> On 07/21/2015 06:51 PM, Bill Fischofer wrote: >>> > >> >>> > >> The problem is twofold: >>> > >> >>> > >> 1. include/odp/api/ is supposed to contain pubic APIs that each >>> > >> platform implements. As such, having linux-generic #defines in the >>> > >> config.h file in this location is inconsistent. So this patch >>> introduces >>> > >> actual APIs that are platform independent. So odp_config_pools() >>> tells you >>> > >> the number of pools on this platform. >>> > >> >>> > >> 2. At the same time, some programs use the #defines directly to do >>> > >> things like dimension arrays, so these #defines (as well as the >>> > >> implementations of the public config APIs now live in >>> > >> platform/<name>/include/odp/config.h >>> > >> >>> > >> So no change for applications, however now each platform can easily >>> > >> define their own limits without having to edit the >>> include/odp/api/config.h >>> > >> file. >>> > >> >>> > >> On Tue, Jul 21, 2015 at 11:45 AM, Nicolas Morey-Chaisemartin < >>> > >> <[email protected]>[email protected]> wrote: >>> > >> >>> > >>> Just for my information, why do we need this? >>> > >>> >>> > >>> >>> > >>> On 07/21/2015 06:42 PM, Bill Fischofer wrote: >>> > >>> >>> > >>> Please ignore this. Resubmitting with proper API-NEXT tag. >>> > >>> >>> > >>> On Tue, Jul 21, 2015 at 11:40 AM, Bill Fischofer < >>> > >>> <[email protected]>[email protected]> wrote: >>> > >>> >>> > >>>> Move platform-specific #defines for limits from the public API to >>> > >>>> the platform directory and add public APIs for each of them. >>> > >>>> >>> > >>>> Signed-off-by: Bill Fischofer < <[email protected]> >>> > >>>> [email protected]> >>> >>> > >>>> >>> > >>>> --- >>> > >>>> include/odp/api/config.h | 61 ++++++----- >>> > >>>> platform/linux-generic/include/odp/config.h | 156 >>> > >>>> ++++++++++++++++++++++++++++ >>> > >>>> 2 files changed, 192 insertions(+), 25 deletions(-) >>> > >>>> >>> > >>>> diff --git a/include/odp/api/config.h b/include/odp/api/config.h >>> > >>>> index b5c8fdd..a57c76b 100644 >>> > >>>> --- a/include/odp/api/config.h >>> > >>>> +++ b/include/odp/api/config.h >>> > >>>> @@ -19,50 +19,58 @@ extern "C" { >>> > >>>> #endif >>> > >>>> >>> > >>>> /** @defgroup odp_config ODP CONFIG >>> > >>>> - * Macro for maximum number of resources in ODP. >>> > >>>> + * Platform-specific configuration limits. >>> > >>>> * @{ >>> > >>>> */ >>> > >>>> >>> > >>>> /** >>> > >>>> * Maximum number of threads >>> > >>>> + * @return The maximum number of threads supported by this >>> platform >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_MAX_THREADS 128 >>> > >>>> +int odp_config_max_threads(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Maximum number of pools >>> > >>>> + * @return The maximum number of pools supported by this platform >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_POOLS 16 >>> > >>>> +int odp_config_pools(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Maximum number of queues >>> > >>>> + * @return The maximum number of queues supported by this >>> platform >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_QUEUES 1024 >>> > >>>> +int odp_config_queues(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Number of scheduling priorities >>> > >>>> + * @return The number of scheduling priorities supported by this >>> > >>>> platform >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_SCHED_PRIOS 8 >>> > >>>> +int odp_config_sched_prios(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Maximum number of packet IO resources >>> > >>>> + * @return The maximum number of packet I/O resources supported >>> by this >>> > >>>> + * platform >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_PKTIO_ENTRIES 64 >>> > >>>> +int odp_config_pktio_entries(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Minimum buffer alignment >>> > >>>> * >>> > >>>> - * This defines the minimum supported buffer alignment. Requests >>> for >>> > >>>> values >>> > >>>> - * below this will be rounded up to this value. >>> > >>>> + * @return The minimum buffer alignment supported by this >>> platform >>> > >>>> + * @note Requests for values below this will be rounded up to >>> this >>> > >>>> value. >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_BUFFER_ALIGN_MIN 16 >>> > >>>> +int odp_config_buffer_align_min(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Maximum buffer alignment >>> > >>>> * >>> > >>>> * This defines the maximum supported buffer alignment. Requests >>> for >>> > >>>> values >>> > >>>> * above this will fail. >>> > >>>> + * >>> > >>>> + * @return The maximum buffer alignment supported by this >>> platform >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_BUFFER_ALIGN_MAX (4*1024) >>> > >>>> +int odp_config_buffer_align_max(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Default packet headroom >>> > >>>> @@ -72,11 +80,9 @@ extern "C" { >>> > >>>> * allocated packets. Implementations may reserve a larger than >>> > >>>> minimum headroom >>> > >>>> * size e.g. due to HW or a protocol specific alignment >>> requirement. >>> > >>>> * >>> > >>>> - * @internal In linux-generic implementation: >>> > >>>> - * The default value (66) allows a 1500-byte packet to be >>> received >>> > >>>> into a single >>> > >>>> - * segment with Ethernet offset alignment and room for some >>> header >>> > >>>> expansion. >>> > >>>> + * @return Default packet headroom in bytes >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_PACKET_HEADROOM 66 >>> > >>>> +int odp_config_packet_headroom(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Default packet tailroom >>> > >>>> @@ -84,10 +90,11 @@ extern "C" { >>> > >>>> * This defines the minimum number of tailroom bytes that newly >>> > >>>> created packets >>> > >>>> * have by default. The default apply to both ODP packet input and >>> user >>> > >>>> * allocated packets. Implementations are free to add to this as >>> > >>>> desired >>> > >>>> - * without restriction. Note that most implementations will >>> > >>>> automatically >>> > >>>> - * consider any unused portion of the last segment of a packet as >>> > >>>> tailroom >>> > >>>> + * without restriction. >>> > >>>> + * >>> > >>>> + * @return The default packet tailroom in bytes >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_PACKET_TAILROOM 0 >>> > >>>> +int odp_config_packet_tailroom(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Minimum packet segment length >>> > >>>> @@ -95,8 +102,10 @@ extern "C" { >>> > >>>> * This defines the minimum packet segment buffer length in bytes. >>> The >>> > >>>> user >>> > >>>> * defined segment length (seg_len in odp_pool_param_t) will be >>> > >>>> rounded up into >>> > >>>> * this value. >>> > >>>> + * >>> > >>>> + * @return The minimum packet seg_len supported by this platform >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_PACKET_SEG_LEN_MIN (1598) >>> > >>>> +int odp_config_packet_seg_len_min(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Maximum packet segment length >>> > >>>> @@ -104,28 +113,30 @@ extern "C" { >>> > >>>> * This defines the maximum packet segment buffer length in bytes. >>> The >>> > >>>> user >>> > >>>> * defined segment length (seg_len in odp_pool_param_t) must not be >>> > >>>> larger than >>> > >>>> * this. >>> > >>>> + * >>> > >>>> + * @return The maximum packet seg_len supported by this platform >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_PACKET_SEG_LEN_MAX (64*1024) >>> > >>>> +int odp_config_packet_seg_len_max(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * Maximum packet buffer length >>> > >>>> * >>> > >>>> * This defines the maximum number of bytes that can be stored >>> into a >>> > >>>> packet >>> > >>>> - * (maximum return value of odp_packet_buf_len()). Attempts to >>> allocate >>> > >>>> + * (maximum return value of odp_packet_buf_len(void)). Attempts >>> to >>> > >>>> allocate >>> > >>>> * (including default head- and tailrooms) or extend packets to >>> sizes >>> > >>>> larger >>> > >>>> * than this limit will fail. >>> > >>>> * >>> > >>>> - * @internal In linux-generic implementation: >>> > >>>> - * - The value MUST be an integral number of segments >>> > >>>> - * - The value SHOULD be large enough to accommodate jumbo >>> packets (9K) >>> > >>>> + * @return The maximum packet buffer length supported by this >>> platform >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_PACKET_BUF_LEN_MAX >>> (ODP_CONFIG_PACKET_SEG_LEN_MIN*6) >>> > >>>> +int odp_config_packet_buf_len_max(void); >>> > >>>> >>> > >>>> /** Maximum number of shared memory blocks. >>> > >>>> * >>> > >>>> * This the the number of separate SHM areas that can be reserved >>> > >>>> concurrently >>> > >>>> + * >>> > >>>> + * @return The maximum number of shm areas supported by this >>> platform >>> > >>>> */ >>> > >>>> -#define ODP_CONFIG_SHM_BLOCKS (ODP_CONFIG_POOLS + 48) >>> > >>>> +int odp_config_shm_blocks(void); >>> > >>>> >>> > >>>> /** >>> > >>>> * @} >>> > >>>> diff --git a/platform/linux-generic/include/odp/config.h >>> > >>>> b/platform/linux-generic/include/odp/config.h >>> > >>>> index 6fecd38..016397e 100644 >>> > >>>> --- a/platform/linux-generic/include/odp/config.h >>> > >>>> +++ b/platform/linux-generic/include/odp/config.h >>> > >>>> @@ -17,6 +17,162 @@ >>> > >>>> extern "C" { >>> > >>>> #endif >>> > >>>> >>> > >>>> +/** >>> > >>>> + * Maximum number of threads >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_MAX_THREADS 128 >>> > >>>> +static inline int odp_config_max_threads(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_MAX_THREADS; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Maximum number of pools >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_POOLS 16 >>> > >>>> +static inline int odp_config_pools(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_POOLS; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Maximum number of queues >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_QUEUES 1024 >>> > >>>> +static inline int odp_config_queues(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_QUEUES; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Number of scheduling priorities >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_SCHED_PRIOS 8 >>> > >>>> +static inline int odp_config_sched_prios(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_SCHED_PRIOS; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Maximum number of packet IO resources >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_PKTIO_ENTRIES 64 >>> > >>>> +static inline int odp_config_pktio_entries(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_PKTIO_ENTRIES; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Minimum buffer alignment >>> > >>>> + * >>> > >>>> + * This defines the minimum supported buffer alignment. Requests >>> for >>> > >>>> values >>> > >>>> + * below this will be rounded up to this value. >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_BUFFER_ALIGN_MIN 16 >>> > >>>> +static inline int odp_config_buffer_align_min(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_BUFFER_ALIGN_MIN; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Maximum buffer alignment >>> > >>>> + * >>> > >>>> + * This defines the maximum supported buffer alignment. Requests >>> for >>> > >>>> values >>> > >>>> + * above this will fail. >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_BUFFER_ALIGN_MAX (4*1024) >>> > >>>> +static inline int odp_config_buffer_align_max(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_BUFFER_ALIGN_MAX; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Default packet headroom >>> > >>>> + * >>> > >>>> + * This defines the minimum number of headroom bytes that newly >>> > >>>> created packets >>> > >>>> + * have by default. The default apply to both ODP packet input >>> and user >>> > >>>> + * allocated packets. Implementations may reserve a larger than >>> > >>>> minimum headroom >>> > >>>> + * size e.g. due to HW or a protocol specific alignment >>> requirement. >>> > >>>> + * >>> > >>>> + * @internal In linux-generic implementation: >>> > >>>> + * The default value (66) allows a 1500-byte packet to be >>> received >>> > >>>> into a single >>> > >>>> + * segment with Ethernet offset alignment and room for some >>> header >>> > >>>> expansion. >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_PACKET_HEADROOM 66 >>> > >>>> +static inline int odp_config_packet_headroom(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_PACKET_HEADROOM; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Default packet tailroom >>> > >>>> + * >>> > >>>> + * This defines the minimum number of tailroom bytes that newly >>> > >>>> created packets >>> > >>>> + * have by default. The default apply to both ODP packet input >>> and user >>> > >>>> + * allocated packets. Implementations are free to add to this as >>> > >>>> desired >>> > >>>> + * without restriction. Note that most implementations will >>> > >>>> automatically >>> > >>>> + * consider any unused portion of the last segment of a packet as >>> > >>>> tailroom >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_PACKET_TAILROOM 0 >>> > >>>> +static inline int odp_config_packet_tailroom(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_PACKET_TAILROOM; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Minimum packet segment length >>> > >>>> + * >>> > >>>> + * This defines the minimum packet segment buffer length in >>> bytes. The >>> > >>>> user >>> > >>>> + * defined segment length (seg_len in odp_pool_param_t) will be >>> > >>>> rounded up into >>> > >>>> + * this value. >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_PACKET_SEG_LEN_MIN 1598 >>> > >>>> +static inline int odp_config_packet_seg_len_min(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_PACKET_SEG_LEN_MIN; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Maximum packet segment length >>> > >>>> + * >>> > >>>> + * This defines the maximum packet segment buffer length in >>> bytes. The >>> > >>>> user >>> > >>>> + * defined segment length (seg_len in odp_pool_param_t) must not >>> be >>> > >>>> larger than >>> > >>>> + * this. >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_PACKET_SEG_LEN_MAX (64*1024) >>> > >>>> +static inline int odp_config_packet_seg_len_max(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_PACKET_SEG_LEN_MAX; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** >>> > >>>> + * Maximum packet buffer length >>> > >>>> + * >>> > >>>> + * This defines the maximum number of bytes that can be stored >>> into a >>> > >>>> packet >>> > >>>> + * (maximum return value of odp_packet_buf_len(void)). Attempts >>> to >>> > >>>> allocate >>> > >>>> + * (including default head- and tailrooms) or extend packets to >>> sizes >>> > >>>> larger >>> > >>>> + * than this limit will fail. >>> > >>>> + * >>> > >>>> + * @internal In linux-generic implementation: >>> > >>>> + * - The value MUST be an integral number of segments >>> > >>>> + * - The value SHOULD be large enough to accommodate jumbo >>> packets (9K) >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_PACKET_BUF_LEN_MAX >>> (ODP_CONFIG_PACKET_SEG_LEN_MIN*6) >>> > >>>> +static inline int odp_config_packet_buf_len_max(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_PACKET_BUF_LEN_MAX; >>> > >>>> +} >>> > >>>> + >>> > >>>> +/** Maximum number of shared memory blocks. >>> > >>>> + * >>> > >>>> + * This the the number of separate SHM areas that can be reserved >>> > >>>> concurrently >>> > >>>> + */ >>> > >>>> +#define ODP_CONFIG_SHM_BLOCKS (ODP_CONFIG_POOLS + 48) >>> > >>>> +static inline int odp_config_shm_blocks(void) >>> > >>>> +{ >>> > >>>> + return ODP_CONFIG_SHM_BLOCKS; >>> > >>>> +} >>> > >>>> + >>> > >>>> #include <odp/api/config.h> >>> > >>>> >>> > >>>> #ifdef __cplusplus >>> > >>>> -- >>> > >>>> 2.1.4 >>> > >>>> >>> > >>>> >>> > >>> >>> > >>> >>> > >>> _______________________________________________ >>> > >>> lng-odp mailing [email protected]:// >>> lists.linaro.org/mailman/listinfo/lng-odp >>> > >>> >>> > >>> >>> > >>> >>> > >>> _______________________________________________ >>> > >>> lng-odp mailing list >>> > >>> [email protected] >>> > >>> https://lists.linaro.org/mailman/listinfo/lng-odp >>> > >>> >>> > >>> >>> > >> >>> > >> >>> > > >>> > > _______________________________________________ >>> > > lng-odp mailing list >>> > > [email protected] >>> > > https://lists.linaro.org/mailman/listinfo/lng-odp >>> > > >>> > > >>> > >>> > >>> > -- >>> > Mike Holmes >>> > Technical Manager - Linaro Networking Group >>> > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM >>> SoCs >>> >>> >> > > > -- > Mike Holmes > Technical Manager - Linaro Networking Group > Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs > > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
