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/12/09 14:19:58 UTC

[GitHub] [incubator-nuttx] hartmannathan commented on pull request #2488: libs/libc: correct the getrandom(2) prototype

hartmannathan commented on pull request #2488:
URL: https://github.com/apache/incubator-nuttx/pull/2488#issuecomment-741800372


   > Recently, it seems that the objectives of the OS have shifted. Historically, for a dozen years, the objective has been to be a Unix-work alike and to conform strictly to the requirements of a Unix system as specified at OpenGroup.org. This is still stated pretty clearly in the INVIOLABLES.md:
   > 
   > ```
   > ## Strict POSIX compliance
   > 
   >   - Strict conformance to the portable standard OS interface as defined at
   >     OpenGroup.org.
   >   - A deeply embedded system requires some special support.  Special
   >     support must be minimized.
   >   - The portable interface must never be compromised only for the sake of
   >     expediency.
   >   - Expediency or even improved performance are not justifications for
   >     violation of the strict POSIX interface.
   > ```
   > 
   > Today, I think that objective has morphed; the OS is now treated like a Linux work-alike system. That is not necessarily bad, it is just a different objective. The only "bad" thing about this is that it happened with no conscious consent of the community.
   > 
   > As a standard, Unix-like OS, inclusion of non-standard Linux interfaces is inappropriate; as a Linux work-alike OS, it is almost mandatory to include these non-standard interfaces. Being another Linux clone is not a very lofty objective for an OS although it many be practical for businesses who want to host Linux applications on NuttX.
   
   Thinking out loud here: What about a compromise: by default NuttX is a Unix-like OS with POSIX interface as originally intended. In addition, if the user wants certain Linux-like APIs, the user could activate a new Kconfig option, say, CONFIG_LINUX_COMPAT. Likewise, if the user wants certain BSD-like APIs, a similar Kconfig option CONFIG_BSD_COMPAT could exist... The idea being to give people a way to add Linux/BSD APIs they need/want, but keeping them optional so that other users could exclude them.


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