A few points of clarification. First, we were talking about using the existing errno variable. If we want to introduce an equivalent odp_errno (not a bad suggestion) then I see little reason in sticking with the cryptic errno.h codes which have all the drawbacks that Victor and Ola have mentioned. The only reason I can see for sticking with errno and the existing codes is so that an ODP error handler could call perror() and have the code translated into something readable, but that's a bit of a stretch and not likely to extend well as more ODP functions and features get added over time.
We do need to be concerned with ODP interoperability both with existing code and future extensions. On Tue, Sep 2, 2014 at 1:16 PM, Ola Liljedahl <[email protected]> wrote: > On 2 September 2014 19:23, Victor Kamensky <[email protected]> > wrote: > >> Hi, >> >> Sorry, I missed the point where we jumped to use of errno. >> I would rather leave it to POSIX and not to mess with it. IMHO >> it is quite archaic mechanism even in POSIX (recall movement >> of errno from global to TLS). >> >> Also I am not sure are we talking about using errno variable >> by ODP library calls or reusing errno.h enumeration values for >> some other purposes, and/or adding new values to errno. >> >> In either case I don't think it is good idea. Few examples: >> >> o If you introduce new errno values that current system >> POSIX implementation does not understand how strerror >> function will work? I.e how it will know strings for new values >> > We can't introduce new errno codes. We would have to use those > that exist, a common subset (e.g. defined by POSIX). Sometimes the > match between what we want to express and the actual errno code > might be strained. > > >> o If ODP uses errno TLS it could be messed up with other >> POSIX calls. I.e if my app have signal handler and that signal >> handler calls will set errno value, so when ODP call comes >> back its error value will have nothing to do with ongoing ODP >> call. BTW I found this issue as one of archaic mechanism of >> POSIX errno itself. Or if ODP implementation stores errno but then >> calls app logging callback. POSIX calls from that logging >> callback may reset errno, so ODP implementation >> should always set errno after any possible logging callback. >> > Possibly this is a good reason for creating odp_errno. > Not all API calls are suitable for returning the errno code directly. > What if a call returns a pointer or some abstract handle? It is not > obvious how these calls would also be able to return errno codes. > odp_errno might not be beautiful but it is a proven concept with known > problems and workarounds. > > >> >> o Reusing errno.h values as return values of some other functions >> does not make much sense either, unless we are talking about very >> simple cases like EINVAL, etc >> > I assume most usages would be for codes like EINVAL, ENOMEM etc. > I actually want a code to return when the implementation runs out of > some resource whose "cardinality" (or capacity) is specified by the user. > ENOMEM does not feel right, it is not memory in general we are lacking. > > >> >> Instead I think ODP should have its own error codes, and either >> return them during API calls (preferable to me) or introduce another >> TLS variables like odp_errno and use it in the same style as errno is >> used by POSIX. >> > If we are not careful, we will end up with a similar jumble of error codes > as POSIX and different Unix-systems. We would need a strict maintainer > of odp_errno.h who only adds very generic error codes that can be reused > by different ODP components and by different implementations. > > E.g. > Invalid parameter (general parameter errors) > Object not found (when doing lookups etc) > Out of memory > Out of specific resource (could be HW resource or something created > and specified by the user). > > > > >> >> Thanks, >> Victor >> >> >> On 2 September 2014 09:56, Wiles, Roger Keith <[email protected]> >> wrote: >> > >> > For errno we are going to use POSIX errno values. >> > >> > Found this one from open group, which I believe to be the current IEEE >> std: >> > http://pubs.opengroup.org/onlinepubs/9699919799/ >> > >> > Will the above reference be OK with everyone as a reference for ERRNO >> names? Linux man page seem to suggest it is following that standard. >> > >> > It appears the standard does not define the value only the name of the >> errno. I had not look directly at the standard before :-( Just assuming the >> applications must be compiled with the system it will be run. I assume we >> are not trying to be binary compatible here. >> > >> > After tracking down the errno values/defines on my Ubuntu 14.04 system >> they really love to hide them now a days. >> > >> > /usr/include/sys/errno.h —> >> > /usr/include/errno.h —> >> > /usr/include/bits/errno.h —> >> > /usr/include/linux/errno.h —> >> > /usr/include/asm/errno.h —> >> > >> /usr/include/asm-generic/errno.h —> >> > >> /usr/include/asm-generic/errno-base.h —> >> > >> /usr/include/asm-generic/errno.h >> > The last two define most of the defines we are interested in for ODP, >> but a few of the ones above define a few extras :-( >> > >> > As long as we use the same define names then we should be OK. >> > >> > If ODP needs a set of defines not able to be mapped to POSIX then we >> need to define a name space to hold these defines similar to what Bill was >> suggesting with some type of prefix for all ODP errnos. The platform should >> do the same, but this is were the problems begin for the application. The >> application will need to include platform specific errno defines when >> building with a given platform (ifdef's), so the applications can not be >> binary compatible across different platforms. >> > >> > Does this summarize the errno discussion today and hopefully add some >> more definition around how ODP uses errnos? >> > >> > Here is a link that someone produced by platform, which was a lot of >> work IMO :-) and may not be up to date. >> > http://www.ioplex.com/~miallen/errcmp.html >> > >> > Thanks >> > ++Keith >> > >> > 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 > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
