Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A error in include/errno.h? #856

Closed
yanyunyouyou opened this issue Apr 24, 2020 · 3 comments
Closed

A error in include/errno.h? #856

yanyunyouyou opened this issue Apr 24, 2020 · 3 comments

Comments

@yanyunyouyou
Copy link
Contributor

yanyunyouyou commented Apr 24, 2020

This logic seems to be wrong,(&& !defined(KERNEL))seems redundant.
This error looks like copying a line of code, changing it, but forgetting to delete the extra parts.
To be honest, I often make this kind of mistakes.

#elif defined(CONFIG_BUILD_KERNEL) && !defined(__KERNEL__)
#  if defined(__KERNEL__)
   /* Kernel build.  Kernel code has direct access */

#    define __DIRECT_ERRNO_ACCESS 1

#  else
   /* User libraries for the kernel.  Only indirect access from user
    * libraries
   */

#    undef __DIRECT_ERRNO_ACCESS
#  endif
#endif
@patacongo
Copy link
Contributor

patacongo commented Apr 24, 2020

This logic seems to be wrong,(**&& !defined(KERNEL**))seems redundant.
This error looks like copying a line of code, changing it, but forgetting to delete the extra parts.
To be honest, I often make this kind of mistakes.

#elif defined(CONFIG_BUILD_KERNEL) && !defined(KERNEL)

No, it is not redundant CONFIGI_BUILD_KERNEL and __KERNEL__ mean very different things. The first is a build mode much like Linux where the kernel is built as a separately linked blob and applications a build as separately linked process blobs.

__KERNEL__ is an indication that we are currently compiling a portion of the kernel code. __KERNEL__ is valid is all build modes.

So the too definitions are not related and it is correct to specify both.

# if defined(**KERNEL**)

/* Kernel build. Kernel code has direct access */
# define __DIRECT_ERRNO_ACCESS 1
# else

/* User libraries for the kernel. Only indirect access from user
* libraries
*/
# undef __DIRECT_ERRNO_ACCESS
# endif

#endif

This is also correct. When we are build internal components of the OS then __KERNEL__ will be defined and is is correct to access the errno variable in a different way by directly accessin OS internal data.

Code that is not part of the internal OS components must use the indirect method by accessing the fake variable errno. That is indirect in the since the errno is really a function call and may even translate to an OS system call in certain build modes.

So it all looks correct to me and all makes good sense.

@yanyunyouyou
Copy link
Contributor Author

Thank you for your detailed reply. I need some time to understand. As an electronic engineer, I am not familiar with complex kernel compilation. Thank you again for your reply.

@xiaoxiang781216
Copy link
Contributor

@yanyunyouyou I will close this issue since @patacongo already gave a detailed explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants