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.
Bill On Thursday, December 18, 2014, Ola Liljedahl <[email protected]> wrote: > On 18 December 2014 at 16:47, Taras Kondratiuk > <[email protected] <javascript:;>> wrote: > > On 12/18/2014 05:41 PM, Savolainen, Petri (NSN - FI/Espoo) wrote: > >> > >> > >> > >>> -----Original Message----- > >>> From: [email protected] <javascript:;> [mailto:lng-odp- > <javascript:;> > >>> [email protected] <javascript:;>] On Behalf Of ext Taras > Kondratiuk > >>> Sent: Thursday, December 18, 2014 4:36 PM > >>> To: Bill Fischofer; [email protected] <javascript:;> > >>> 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] > <javascript:;>> > >>> > >>> > >>> 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] > <javascript:;>> > >>> > >>> 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] <javascript:;> > > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
