On 2 September 2014 10:30, Wiles, Roger Keith <[email protected]> wrote: > > 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.
Just run into this. "ODP API Design Guidelines" https://www.google.com/url?q=https%3A%2F%2Fdocs.google.com%2Fa%2Flinaro.org%2Fdocument%2Fd%2F15ltgSZolCeN66Xmx9rBSAzpxujia0wj4iPrqb2yzlb8%2Fedit in section "Use of errno" says "ODP APIs SHOULD make use of the thread-local variable errno" Personally I would more agree with quoted sentence above so "We are not going to use the variable ‘errno’". If we agree that it is the case document should be corrected. I cross referenced inconsistency in both places mail thread and document comment, so it would be tracked. Thanks, Victor >> >> 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
