exit has to be assert(), it's actually bug if buffer type do not match one
of these:

    if (buf_type == ODP_BUFFER_TYPE_RAW) {
        hdr_size = sizeof(odp_raw_buffer_hdr_t);
    } else if (buf_type == ODP_BUFFER_TYPE_PACKET) {
        hdr_size = sizeof(odp_packet_hdr_t);
    } else if (buf_type == ODP_BUFFER_TYPE_TIMEOUT) {
        hdr_size = sizeof(odp_timeout_hdr_t);
    } else if (buf_type == ODP_BUFFER_TYPE_ANY) {
        hdr_size = sizeof(odp_any_buffer_hdr_t);
    } else {
        ODP_ERR("odp_buffer_pool_create: Bad type %i\n", buf_type);
        exit(0);
    }

Btw, for ks2 we do no have exit(0) there.



On 27 August 2014 05:08, Bill Fischofer <[email protected]> wrote:

> Many of the linux-generic routines that were written early in the project
> took various shortcuts in this area.  They need to be standardized as part
> of the ODP v1.0 cleanup/packaging/validation/documentation effort post-LCU.
>  We should start compiling a list of these and get BPs created for these
> now and at LCU.
>
> ODP routines, should not call exit() or similar global "give up" routines
> but should provide appropriate error returns in the case of most problems.
>  In the specific case of odp_buffer_pool_create(), it should never abort.
>  The parameter list also does not reflect the current design so that too
> will need to be harmonized.
>
> Bill
>
>
> On Tue, Aug 26, 2014 at 7:30 PM, Wiles, Roger Keith <
> [email protected]> wrote:
>
>>
>>  On Aug 26, 2014, at 4:25 PM, Mike Holmes <[email protected]> wrote:
>>
>>   The  odp_buffer_pool_create  function has a return code that defaults
>> to  ODP_BUFFER_POOL_INVALID, although the API header file doxygen comment
>> does not indicate that there is any error return code possible.
>> I was going to add that information however there truly is no error
>> returned because link_bufs actually calls exit(0) on error.
>>
>>  My question is do we update odp_buffer_pool_create docs to say this
>> function may never return, or should link_bufs be rewritten ?
>>
>>  I would normally say we need to remove the exit(0)  but presumably this
>> was done as as an optimization ?  In which case we just need to document it
>> properly ?
>>
>>  Thoughts ?
>>
>>
>>  odp_buffer_pool_t odp_buffer_pool_create(const char *name,
>>                                          void *base_addr, uint64_t size,
>>                                          size_t buf_size, size_t
>> buf_align,
>>                                          int buf_type)
>> {
>>         odp_buffer_pool_t i;
>>         pool_entry_t *pool;
>>         odp_buffer_pool_t pool_id = ODP_BUFFER_POOL_INVALID;
>>
>>          for (i = 0; i < ODP_CONFIG_BUFFER_POOLS; i++) {
>>                 pool = get_pool_entry(i);
>>
>>                  LOCK(&pool->s.lock);
>>
>>                  if (pool->s.buf_base == 0) {
>>                         /* found free pool */
>>
>>                          strncpy(pool->s.name, name,
>>                                 ODP_BUFFER_POOL_NAME_LEN - 1);
>>                         pool->s.name[ODP_BUFFER_POOL_NAME_LEN - 1] = 0;
>>                         pool->s.pool_base_addr = base_addr;
>>                         pool->s.pool_size      = size;
>>                         pool->s.user_size      = buf_size;
>>                         pool->s.user_align     = buf_align;
>>                         pool->s.buf_type       = buf_type;
>>
>>                          link_bufs(pool); NEVER returns on some errors
>>
>>
>>  I would want this function to not do an exit() call without allowing the
>> application to caught the error. It would mean the link_bufs() routine
>> would need to return and error/error code instead of exiting. Having
>> something exit is not a very friendly action IMO.
>>
>>
>>                          UNLOCK(&pool->s.lock);
>>
>>                          pool_id = i;
>>                         break;
>>                 }
>>
>>                  UNLOCK(&pool->s.lock);
>>         }
>>
>>          return pool_id;
>> }
>>
>>
>>
>>  --
>> *Mike Holmes*
>> Linaro Technical Manager / Lead
>> LNG - ODP
>>  _______________________________________________
>> lng-odp mailing list
>> [email protected]
>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>>  *Keith **Wiles*, Principal Technologist with CTO office, *Wind River *mobile
>> 972-213-5533
>>
>>
>> _______________________________________________
>> lng-odp mailing list
>> [email protected]
>> http://lists.linaro.org/mailman/listinfo/lng-odp
>>
>>
>
> _______________________________________________
> lng-odp mailing list
> [email protected]
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp

Reply via email to