That's not a question I can answer. I'm just implementing what was specified. :)
On Thu, Dec 18, 2014 at 1:27 PM, Ola Liljedahl <[email protected]> wrote: > > 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
