On Sep 2, 2014, at 12:23 PM, 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). We are not going to use the variable ‘errno’ just the ERRNO define names as a good starting point for error codes. > > 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 Every one that defines a platform specific errno value will have to deal with that problem and that is what happens today in any system, correct? > > 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. > > 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 > > 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. > > 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 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
