On 18 December 2014 at 19:54, Bill Fischofer <[email protected]> wrote: > There is no architectural requirement that they be distinct and, as Raras > noted, most implementations will just make them synonyms. That's why the > patch is classified as a documentation change--there's no actual change in > observable behavior. If the semantics is the same, why then not have only one symbolic constant? How is the architecture better by having two symbolic constants that mean the same?
> > Bill > > On Thursday, December 18, 2014, Ola Liljedahl <[email protected]> > wrote: >> >> On 18 December 2014 at 16:47, Taras Kondratiuk >> <[email protected]> wrote: >> > On 12/18/2014 05:41 PM, Savolainen, Petri (NSN - FI/Espoo) wrote: >> >> >> >> >> >> >> >>> -----Original Message----- >> >>> From: [email protected] [mailto:lng-odp- >> >>> [email protected]] On Behalf Of ext Taras Kondratiuk >> >>> Sent: Thursday, December 18, 2014 4:36 PM >> >>> To: Bill Fischofer; [email protected] >> >>> Subject: Re: [lng-odp] [PATCH] Documentation: Change >> >>> odp_buffer_pool_info_t output >> >>> >> >>> On 12/16/2014 01:43 PM, Bill Fischofer wrote: >> >>>> >> >>>> Change odp_buffer_pool_info() output to use ODP_SHM_INVALID instead >> >>>> of >> >>>> ODP_SHM_NULL. >> >>>> >> >>>> Signed-off-by: Bill Fischofer <[email protected]> >> >>> >> >>> >> >>> To follow our naming convention it should be named: >> >>> api: buffer: Change odp_buffer_pool_info_t output >> >>> >> >>> Otherwise >> >>> Reviewed-by: Taras Kondratiuk <[email protected]> >> >>> >> >>> Should ODP_SHM_NULL definition be removed completely now from API? >> >> >> >> >> >> No. The idea is that user input param is XXX_NULL if the param is >> >> optional >> >> and the user don't specify a handle. Output from ODP would be always >> >> XXX_INVALID or valid handle. >> >> >> >> >> >> shm = odp_shm_reserve(...) // returns INVALID >> >> >> >> odp_buffer_pool_create(..., shm, ...); // I care but didn't check the >> >> shm >> >> output >> >> >> >> vs. >> >> >> >> odp_buffer_pool_create(..., ODP_SHM_NULL, ...); // I don't care >> > >> > >> > Sorry if it was already discussed before, but what is the advantage of >> > having both NULL and INVALID? Why not to leave only one of them? >> > I assume on most of platforms they will anyway map to the same value. >> If Petri's example above should work (as I expect it to work), they >> cannot have the same value. >> >> I think it is confusing to provide both a _NULL and an _INVALID >> symbol. Perhaps the _NULL symbol should be renamed to _DEFAULT or >> something else that is semantically far away from _INVALID. >> >> The odp_buffer_pool_create() function could also specify that >> ODP_SHM_INVALID has the meaning of do default behavior. If the user is >> too lazy to check the return value of odp_shm_reserve() and >> unexpectedly passes ODP_SHM_INVALID, it could be viewed as their >> problem. >> > >> > >> > _______________________________________________ >> > 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
