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/09/28 15:53:34 UTC

[GitHub] [incubator-nuttx] xiaoxiang781216 edited a comment on pull request #1886: Allows network monitoring (apps repo) using polling and allows the board to provide the IP config at runtime.

xiaoxiang781216 edited a comment on pull request #1886:
URL: https://github.com/apache/incubator-nuttx/pull/1886#issuecomment-700122353


   > > Here is my thinking, from purely a use case perspective, contrasting: Format, Dependency, Flexibility and Recovery
   > > ...
   > 
   > The important thing is that NO OS interfaces are involved. DHCPC is an application and must reside wholly in user space.
   > 
   > > Minimizing that impact on an embedded system is important.
   > > Maintaining scalability in NuttX is crucial to it's success. (If NuttX gets too Linux-ised it will be useless on the many SoC's is serves)
   > 
   > I don't know who decides what is "too Linux-ised". The important thing is that people must not make up their own operating system interfaces. All operating systems interfaces must be based on standards or at least follow some principles. We follow Linux for two reasons: (1) It provides guidance for how to do many things; How to partition functionality between OS and applications when necessary, What mechanisms to use at the OS interface. It provides good guidance for solving problems. And (2) it makes us compatible with Linux and better able to port Linux code to NuttX.
   > 
   > In this case, the most important principle is that the application must be implemented wholly in user space with no new, non-standard OS interfaces. On that we must be inflexible. The content of files is not so critical. That is not really Linux compatibility; that is compatibility with a common Linux DHCP.client application and I don't there that there are any compatibility concerns. But that usage is still good guidance.
   > 
   > > Keeping it flexible:
   > > The board level abstraction for getting the network settings, had the appeal of total flexibility of how the settings are managed.
   > 
   > NO, no, no. No non-standard, kludgey shit OS interfaces. Never! You need to re-read the INVIOLABLES.
   > 
   > DHCP must never have any custom OS interface. It is an application. It is not a part of the OS and must be implemented wholly in user-space.
   
   Agree, it's easy to save/load EEPROM from userspace. We have done the similar(but more complex) thing for WiFi without touching kernel space:
   https://github.com/apache/incubator-nuttx-apps/blob/master/wireless/wapi/src/util.c
   


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