The key thing is to be consistent to the documentations description of the API I think, currently the odp_buffer_test behaves differently per platform, and neither are correct to the documentation.
On 27 August 2014 05:31, Savolainen, Petri (NSN - FI/Espoo) < [email protected]> wrote: > Hi, > > > > Some exit()s are caused by internal errors (which cannot be recovered > from), so it might be better idea to crash right there rather than return > an error code. > > > > -Petri > > > > > > *From:* ext Bill Fischofer [mailto:[email protected]] > *Sent:* Wednesday, August 27, 2014 4:08 AM > *To:* Wiles, Roger Keith > *Cc:* Mike Holmes; Savolainen, Petri (NSN - FI/Espoo); lng-odp > *Subject:* Re: [lng-odp] RFC odp_buffer_pool_create has no return code it > calls exit(0) > > > > 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 > > > -- *Mike Holmes* Linaro Technical Manager / Lead LNG - ODP
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
