You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by GitBox <gi...@apache.org> on 2020/04/24 04:09:47 UTC

[GitHub] [incubator-nuttx] yanyunyouyou opened a new issue #856: A error in include/errno.h?

yanyunyouyou opened a new issue #856:
URL: https://github.com/apache/incubator-nuttx/issues/856


   
   
   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


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] patacongo commented on issue #856: A error in include/errno.h?

Posted by GitBox <gi...@apache.org>.
patacongo commented on issue #856:
URL: https://github.com/apache/incubator-nuttx/issues/856#issuecomment-618799837


   
   > 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.
   
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] xiaoxiang781216 commented on issue #856: A error in include/errno.h?

Posted by GitBox <gi...@apache.org>.
xiaoxiang781216 commented on issue #856:
URL: https://github.com/apache/incubator-nuttx/issues/856#issuecomment-618964549


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


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] yanyunyouyou commented on issue #856: A error in include/errno.h?

Posted by GitBox <gi...@apache.org>.
yanyunyouyou commented on issue #856:
URL: https://github.com/apache/incubator-nuttx/issues/856#issuecomment-618804046


   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.


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [incubator-nuttx] patacongo edited a comment on issue #856: A error in include/errno.h?

Posted by GitBox <gi...@apache.org>.
patacongo edited a comment on issue #856:
URL: https://github.com/apache/incubator-nuttx/issues/856#issuecomment-618799837


   > 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.
   
   
   


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org