I'm agreeing with you Greg, anything that comes into Apps or the OS must use the socket API.
Then we are in agreement. I am a mother hen and will defend the OS architecture to the teeth (hmm.. hens.. teeth... sorry about the mixed metaphor).
I don't get involved in most code changes. I only turn into the Hulk when the architecture is threatened.
All I am saying is there are applications like dumping the HCI log that really just pretty print the packets. It does not care if it came via a socket or something else. As long as it uses the NuttX API there is no reason to build it twice.
IEEE802.14.5 has both a character driver interface and a network driver interface. But it is awkward and Anthony Merlino has recommended not doing this in the future. Anthony intended to remove the character driver interface before he got distracted. There is nothing that you can do with a character driver that cannot be done with raw socket and, in most cases, there is not a substantial difference in performance (there is more complexity, but not necessary performance overhead). So there is really no functional need for the character driver interfaces.
Having both is also undesirable because it makes routing of received frames complex. Do they go to the network or to the character driver? So I don't think having a sneak character driver interface should be incorporated either.
I suppose having a socket tapped into the HCI layer has the same routing issues.
Then we agree that there is only one Bluetooth stack and it is accessed by via the network. It is better not to have some interim character driver solution because that might get usage and once it has been established, it becomes nearly impossible to remove. We can only allow final implementations utilizing the network interface into the repositories. Interim solutions need to wait until they mature outside of the repositories.
What I will resist is having two Bluetooth stacks: The existing one and one that is just a secret backdoor for getting third party Zephyr code into the OS without following ASF rules and uses a character driver interface. It is the latter than I am opposed to.
