You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by 安超 <an...@xiaomi.com.INVALID> on 2020/08/26 16:40:54 UTC
答复: 答复: [External Mail]Re: defining a BLE GATT server
Mr.Greg, I really don't understand why you are so angry, and there are so many verbal attacks.
I just share a feasibility. What I expect is discussion and respect, not devaluation. If you don't like it, just say it like others.
BRs,
________________________________________
发件人: Gregory Nutt <sp...@gmail.com>
发送时间: 2020年8月27日 0:30
收件人: dev@nuttx.apache.org
主题: Re: 答复: [External Mail]Re: defining a BLE GATT server
> What you should do is to coordinate and and cooperate with the NuttX
> team to get help from the community. If you chose to go your own way
> and not discussion or cooperation with the team, then you are on your
> own. That code will not come into the repository.
>
> If you want to do things correctly and get the benefit of community
> support then you need to communicate, conform, and cooperate. You
> help would be appreciated. The current direction you are taking is
> NOT appreciated and is a waste of your time in the long run. It will
> not be adopted. I will never come into the repositories. It will
> never be supported or used by anyone other than Xiaomi.
>
> If you want the benefit of working in an open source project, be part
> of the team and follow the project architecture and roadmap. Taking
> you own rogue direction isolates you. You will fail in the direction
> you are taking.
Imagine what we could accomplish if we worked together instead you
taking off unilaterally on your own unacceptable, bullshit direction!
We could do a lot which such a terrible solution. We could implement
the roadmap. We could maintain Linux compatible. We could be the world
class implementation, not some sleazy little sneaks illicit Zephyr code
into the code base and then uses it is a moronic, incompatible way.
What you are doing is very bad and would be a disaster for the OS. We
have to resist this in all ways that we are able to.
Of course, if Xiaomi likes this shitty architecture and back-door access
to Zephyr code, go ahead. Just don't degrade the NuttX project with
this garbage. We won't permit that.
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
Re: 答复: 答复: [External Mail]Re: defining a BLE GATT server
Posted by Gregory Nutt <sp...@gmail.com>.
> Let me clarify one thing: The approach we take is a pure userspace solution, it isn't related to NuttX kernel and no plan to upstream it.
That is good to know. Thank you. I will sleep better tonight.
> The major difference is where to put L2CAP/HCI code(userspace v.s. kernelspace) and it isn't too hard to migrate to socket interface once the NuttX kernel has the full and stable L2CAP/HCI support.
> My question is how to finish the Bluetooth stack on the userspace? It will be a huge work to write from scratch(BT, BLE, BLE mesh and BLE Audio).
Since NuttX does not support a user-space Bluetooth stack, I will leave
this up to your internal implementation.
I think that Xiaomi is missing a tremendous opportunity. The reason
that most corporations get involved with open source projects is to
benefit from the open source support from the community. But it always
seems the Xiaomi goes their own way and implements things all on their
own without discussing with the community. That is Xiaomi's loss. You
are losing the power and strength of the open source project.
If you, Chao An, I, Brennan, Matias, and others all worked together with
a common goal and under common architectural principles, I think that we
could accomplish a lot. Much more than Xiaomi could accomplish by
themselves. But that requires, planning, discussion, agreement, and
conformance to a common architecture and roadmap.
Yes Bluetooth is a big job. It is a lot for one person. But if we
share the project as a true open source project, we can do most
anything. There is a lot a strength and talent on this project that you
are ignoring.
For example, I offered to implement the Bluetooth protocol sockets this
morning (my time). Matias is considering a Gatt server.
RE: 答复: 答复: [External Mail]Re: defining a BLE GATT server
Posted by Xiang Xiao <xi...@gmail.com>.
Let me clarify one thing: The approach we take is a pure userspace solution, it isn't related to NuttX kernel and no plan to upstream it.
The major difference is where to put L2CAP/HCI code(userspace v.s. kernelspace) and it isn't too hard to migrate to socket interface once the NuttX kernel has the full and stable L2CAP/HCI support.
My question is how to finish the Bluetooth stack on the userspace? It will be a huge work to write from scratch(BT, BLE, BLE mesh and BLE Audio).
> -----Original Message-----
> From: Gregory Nutt <sp...@gmail.com>
> Sent: Thursday, August 27, 2020 12:46 AM
> To: dev@nuttx.apache.org
> Subject: Re: 答复: 答复: [External Mail]Re: defining a BLE GATT server
>
>
> > Mr.Greg, I really don't understand why you are so angry, and there are so many verbal attacks.
> > I just share a feasibility. What I expect is discussion and respect, not devaluation. If you don't like it, just say it like others.
>
> Yes, I am angry. I am very pissed off that you completely ignored the NuttX architectural roadmap and chose to go your own
> direction. That is offensive (as well as stupid). And I do not want to work with people who cannot work together for common
> architectural goals. The direction you are taking is not going to lead to friendship or cooperation.
>
> Attempts like these to destroy the NuttX architecture will always piss me off. I have a lot invested in this OS and some ignorant
> engineer who ignores that legacy is going make me angry. You would ruin this OS!
>
> You must keep these changes within Xaiomi because they will not be permitted upstream.
>
Re: 答复: 答复: [External Mail]Re: defining a BLE GATT server
Posted by Gregory Nutt <sp...@gmail.com>.
> Mr.Greg, I really don't understand why you are so angry, and there are so many verbal attacks.
> I just share a feasibility. What I expect is discussion and respect, not devaluation. If you don't like it, just say it like others.
Yes, I am angry. I am very pissed off that you completely ignored the
NuttX architectural roadmap and chose to go your own direction. That is
offensive (as well as stupid). And I do not want to work with people
who cannot work together for common architectural goals. The direction
you are taking is not going to lead to friendship or cooperation.
Attempts like these to destroy the NuttX architecture will always piss
me off. I have a lot invested in this OS and some ignorant engineer who
ignores that legacy is going make me angry. You would ruin this OS!
You must keep these changes within Xaiomi because they will not be
permitted upstream.
答复: 答复: [External Mail]Re: defining a BLE GATT server
Posted by 安超 <an...@xiaomi.com.INVALID>.
Hi Greg, Brennan
Okay, it is enough, I think we have all spent enough time discussing this issue!
I agree that this change will not be upstream, Xiaomi will not give up NuttX's Roadmap, which is also Xiang's long-cherished wish.
I will abandon later, Thanks for your precious time.
BRs,
________________________________________
发件人: Brennan Ashton <ba...@brennanashton.com>
发送时间: 2020年8月27日 1:01
收件人: dev@nuttx.apache.org
主题: Re: 答复: [External Mail]Re: defining a BLE GATT server
On Wed, Aug 26, 2020 at 9:56 AM Gregory Nutt <sp...@gmail.com> wrote:
> > Lets try to see how we can move this forward, I'm not fully sure I
> > fully understand the implications of what you were saying about the
> > packet protocol, but I think it is best that we focus the discussion
> > on that in the GitHub issue that I opened about the HCI socket. I can
> > share what I know about the BlueZ interface there with some client
> > examples as appropriate.
> >
> > I'm sure we can find ways to bridge the gap here especially on the
> > application side.
>
> I still would not accept any such change in the OS. And, if merged, I
> would feel compelled to revert the commits.
I'm agreeing with you Greg, anything that comes into Apps or the OS
must use the socket API.
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.
--Brennan
#/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#
Re: 答复: [External Mail]Re: defining a BLE GATT server
Posted by Gregory Nutt <sp...@gmail.com>.
> 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.
Re: 答复: [External Mail]Re: defining a BLE GATT server
Posted by Brennan Ashton <ba...@brennanashton.com>.
On Wed, Aug 26, 2020 at 9:56 AM Gregory Nutt <sp...@gmail.com> wrote:
> > Lets try to see how we can move this forward, I'm not fully sure I
> > fully understand the implications of what you were saying about the
> > packet protocol, but I think it is best that we focus the discussion
> > on that in the GitHub issue that I opened about the HCI socket. I can
> > share what I know about the BlueZ interface there with some client
> > examples as appropriate.
> >
> > I'm sure we can find ways to bridge the gap here especially on the
> > application side.
>
> I still would not accept any such change in the OS. And, if merged, I
> would feel compelled to revert the commits.
I'm agreeing with you Greg, anything that comes into Apps or the OS
must use the socket API.
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.
--Brennan
Re: 答复: [External Mail]Re: defining a BLE GATT server
Posted by Gregory Nutt <sp...@gmail.com>.
On 8/26/2020 10:56 AM, Gregory Nutt wrote:
>
>> Lets bring this back to a constructive place.
>>
>> An Chao I really appreciate the detailed information that you wrote,
>> while I don't think it will be appropriate to include directly
>> upstream it is still valuable to know how you are trying to use this
>> and it helps us make an informed decision moving forward. I think we
>> are going to take more of the BlueZ path forward but I suspect there
>> are ways to allow your internal works to sit nicely on top of that
>> without compromising what we are building here. You see this even in
>> the Linux Kernel where for very specific use cases companies will
>> implement parts of a network stack in user space.
>>
>> Greg I fully understand where you stand and your frustration, you have
>> put a significant part of your life into this project and want to see
>> it grow and not erode. In this case I think you have multiple people
>> on the team who are also saying thanks, but lets make sure we are
>> doing this correctly and not taking shortcuts.
>>
>> Lets try to see how we can move this forward, I'm not fully sure I
>> fully understand the implications of what you were saying about the
>> packet protocol, but I think it is best that we focus the discussion
>> on that in the GitHub issue that I opened about the HCI socket. I can
>> share what I know about the BlueZ interface there with some client
>> examples as appropriate.
>>
>> I'm sure we can find ways to bridge the gap here especially on the
>> application side.
>
> I still would not accept any such change in the OS. And, if merged, I
> would feel compelled to revert the commits.
>
I am not open to violating the architectural principles of the OS. There
is no room for compromise on this topic.
Re: 答复: [External Mail]Re: defining a BLE GATT server
Posted by Gregory Nutt <sp...@gmail.com>.
> Lets bring this back to a constructive place.
>
> An Chao I really appreciate the detailed information that you wrote,
> while I don't think it will be appropriate to include directly
> upstream it is still valuable to know how you are trying to use this
> and it helps us make an informed decision moving forward. I think we
> are going to take more of the BlueZ path forward but I suspect there
> are ways to allow your internal works to sit nicely on top of that
> without compromising what we are building here. You see this even in
> the Linux Kernel where for very specific use cases companies will
> implement parts of a network stack in user space.
>
> Greg I fully understand where you stand and your frustration, you have
> put a significant part of your life into this project and want to see
> it grow and not erode. In this case I think you have multiple people
> on the team who are also saying thanks, but lets make sure we are
> doing this correctly and not taking shortcuts.
>
> Lets try to see how we can move this forward, I'm not fully sure I
> fully understand the implications of what you were saying about the
> packet protocol, but I think it is best that we focus the discussion
> on that in the GitHub issue that I opened about the HCI socket. I can
> share what I know about the BlueZ interface there with some client
> examples as appropriate.
>
> I'm sure we can find ways to bridge the gap here especially on the
> application side.
I still would not accept any such change in the OS. And, if merged, I
would feel compelled to revert the commits.
Re: 答复: [External Mail]Re: defining a BLE GATT server
Posted by Brennan Ashton <ba...@brennanashton.com>.
Lets bring this back to a constructive place.
An Chao I really appreciate the detailed information that you wrote,
while I don't think it will be appropriate to include directly
upstream it is still valuable to know how you are trying to use this
and it helps us make an informed decision moving forward. I think we
are going to take more of the BlueZ path forward but I suspect there
are ways to allow your internal works to sit nicely on top of that
without compromising what we are building here. You see this even in
the Linux Kernel where for very specific use cases companies will
implement parts of a network stack in user space.
Greg I fully understand where you stand and your frustration, you have
put a significant part of your life into this project and want to see
it grow and not erode. In this case I think you have multiple people
on the team who are also saying thanks, but lets make sure we are
doing this correctly and not taking shortcuts.
Lets try to see how we can move this forward, I'm not fully sure I
fully understand the implications of what you were saying about the
packet protocol, but I think it is best that we focus the discussion
on that in the GitHub issue that I opened about the HCI socket. I can
share what I know about the BlueZ interface there with some client
examples as appropriate.
I'm sure we can find ways to bridge the gap here especially on the
application side.
--Brenna
On Wed, Aug 26, 2020 at 9:41 AM 安超 <an...@xiaomi.com.invalid> wrote:
>
> Mr.Greg, I really don't understand why you are so angry, and there are so many verbal attacks.
> I just share a feasibility. What I expect is discussion and respect, not devaluation. If you don't like it, just say it like others.
>
> BRs,
>
> ________________________________________
> 发件人: Gregory Nutt <sp...@gmail.com>
> 发送时间: 2020年8月27日 0:30
> 收件人: dev@nuttx.apache.org
> 主题: Re: 答复: [External Mail]Re: defining a BLE GATT server
>
> > What you should do is to coordinate and and cooperate with the NuttX
> > team to get help from the community. If you chose to go your own way
> > and not discussion or cooperation with the team, then you are on your
> > own. That code will not come into the repository.
> >
> > If you want to do things correctly and get the benefit of community
> > support then you need to communicate, conform, and cooperate. You
> > help would be appreciated. The current direction you are taking is
> > NOT appreciated and is a waste of your time in the long run. It will
> > not be adopted. I will never come into the repositories. It will
> > never be supported or used by anyone other than Xiaomi.
> >
> > If you want the benefit of working in an open source project, be part
> > of the team and follow the project architecture and roadmap. Taking
> > you own rogue direction isolates you. You will fail in the direction
> > you are taking.
>
> Imagine what we could accomplish if we worked together instead you
> taking off unilaterally on your own unacceptable, bullshit direction!
> We could do a lot which such a terrible solution. We could implement
> the roadmap. We could maintain Linux compatible. We could be the world
> class implementation, not some sleazy little sneaks illicit Zephyr code
> into the code base and then uses it is a moronic, incompatible way.
>
> What you are doing is very bad and would be a disaster for the OS. We
> have to resist this in all ways that we are able to.
>
> Of course, if Xiaomi likes this shitty architecture and back-door access
> to Zephyr code, go ahead. Just don't degrade the NuttX project with
> this garbage. We won't permit that.
>
> #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from XIAOMI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!******/#