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/08/26 12:44:40 UTC

[GitHub] [incubator-nuttx] patacongo commented on pull request #1651: [EXPERIMENT/DISCUSS] sim/zblue: zephyr bluetooth stack support

patacongo commented on pull request #1651:
URL: https://github.com/apache/incubator-nuttx/pull/1651#issuecomment-680856039


   @btashton said this in the dev list:
   
   > While I appreciate the need to have a more complete Bluetooth stack working, I am very opposed to this being brought into mainline. It fully bypasses the OS. This would be as if we implemented the full network stack in user space. 
   > 
   > Doing this also ties us to a critical bit of software that we do not maintain which is also not something I could support.
   > 
   > The Bluedroid comparison is a good one, it exists to explicitly work around the Linux stack and further sperate Android from the kernel. This split also let Qualcomm ship there entirely own stack also out of the Kernel. 
   > 
   > 
   > What I will say is that once I implement the HCI socket interface, using the user channel you could easily have zblue run on top of that with no changes to NuttX. Drivers do not have to implement a special tty interface since it can just use the socket interface.  This is the whole point of the user channel and how several years ago I added mesh support outside of the Linux kernel. 
   
   I am in 100% agreement.  I am very opposed to this change because it violates all of the architectural principles that have been established for the NuttX wireless subsystem over the course of about a 2 year discussion in the old Google group.  That architecture and roadmap are documented here:  https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629397
   
   Specifically, the interface to the all complex wireless devices MUST be through the network layer.  Use of character devices in anything other than the most trivial of radios is strictly forbidden.
   
   Xiaomi cannot contribute this crappy implementation only because they are too lazy to follow the established architectural principles as required in the INVIOLABLES.md.  This is wrong and cannot be permitted to happen.
   
   I also believe the underlying approach is unethical.  It takes some of the Zephyr code, downloads it at build time, and builds the unauthorized third party code into the binaries.  The purpose of this is to avoid the NuttX coding standard and to circumvent the ASF's policies for including third party code.  While this approach may meet the legal definitions, it is inherently corrupt at its core.  This approach is not only lazy, inconsistent with the NuttX roadmap, but lacks integrity.
   
   This code must NEVER come into the NuttX master branch.  This is not in the spirit of NuttX, it is not consistent with the NuttX roadmap, custs corners to reduce effort, and lacks integrity.  This is all in contradiction to most of the statements.
   
   I have marked this as a Draft so that it is not accidently merged.  It would have to be reverted if it were merged.
   
   


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