Re: [Dev] [Bluetooth] About NBT

김승구 Fri, 31 Oct 2014 01:06:02 -0700

Title: Samsung Enterprise Portal mySingle

Dear Mr. Martin,

I hope this discussion can be helpful to improve the NTB. :)

Please consider my comments with green color.

• Bluetooth CAPI (bluetooth.c) is a library to be called by applications. To the best of my knowledge, a shared library cannot share the data section between different processes. In my opinion, current implementation has not considered this.

[Martin]Yes, you are right, NTB is using shared library, and shared library can’t share section between different process.

But I do not think it is a problem here.

Firstly, our design philosophy is to provide all Bluetooth service through unified Tizen Core API interface, I think that is also the overall design requirement from Tizen.

Secondly, I can’t understand why different processes need to share data. If you want to share data vconf can be used, besides at BlueZ and Bluez-lib layer also maintain the Bluetooth states, so different processes can easily access/share the same Bluetooth status.

[Kim] May I present one scenario to access bluetooth by different processes. Please let me give one smartphone example.

1. A smartphone user turns the bluetooth on using the setting menu. Then, the bluetooth is enabled state.

2. The user wants to play game that has multi-play function through bluetooth link, so he turns on the game app. that runs on different process with setting app.

3. At that time, bluetooth game app. should check whether the bluetooth is enabled or not using bt_adapter_get_state() API before trying to connect with other game user.

4. In current NTB code, bt_adapter_get_state() checks "initialized", "default_adapter", and "adapter_state" variables before asking to bluez (bluez_adapter_get_property_powered()). In this case, setting app. has specific values of these variables, but the game app. has the values such as initialized=false, default_adapter=NULL, and adapter_state=NULL at the same time.

5. The game app. will get BT_ERROR_* return values from the bluetooth, accordingly it doesn't seem to work properly in this kind of scenario.

In my opinion, some variables have to keep identical value at the same time by different processes. For this scenario, I don't think vconf is appropriate solution.

Lastly, so as to the bt-initialize(), I think it is the right design, The basic concept is using Bluetooth, you need to initialize it, and need not care about whether some other process and the Bluetooth statues, Bluetooth-framework will handle everything. That is the most easy way for application writer. Besides, that CAPI should be compatible with the original design.

[Kim] If you agree the upper scenario, I think the NTB need to consider bluetooth access by different processes at the same time.

But I am still keep open on this topic, if you still think it is a issue, please give me more examples, we can continue to discuss on it. J

[Kim] I hope this comment could be of help. :)

· Error and Exception Handling

[Martin]we already start to work on it. Thanks for your input.

· memory consumption design goal. The memory consumption of current bluetooth-frwk is a result when hfp/share was enabled, but I think the new design did not enable them.

[Martin] I believe we can reach the design goal in the end.

You are right, we got the memory consumption data expectation without HFP support basing on prototype(you know, according the plan decided by “Intel and Samsung comms team”, Samsung will enable tizen-2.x HFP which is based on Samsung’s telephony stack).

But the expectation is reasonable, we did not enable HFP, but at the prototype, we also do nothing on the memory consumption optimization, as I mentioned before, we used gobject which consumes a lot of memory. Removing gobject and other memory consumption optimize work will be done in next stage. After all of the work be done, I believe we definitely will reach the goal.

[Kim] I don't know how much additional memory is required for gobject well and what kind of memory optimization skill will be applied in NTB. It seems to prove why the NTB is memory efficiency in the architectural aspect, not the coding scheme. It is because memory optimization using the coding scheme can also be realized in the current bluetooth framework.

Thank you very much for pointing out the runtime load module and plugin, that is the missed implementation in the design, we will work on it.

· Reduce maintaining efforts

[martin] I believe, both of us agree that this design will make the big version upgrade very easy, after we introduce the bluez-lib design, all the upgrade work will focus on very limited files. I’d like to emphasize that we can’t expect that there will no big change anymore. Upstream always claim to keep stable of API, but they always kept changing the API. Besides, even the small change of BlueZ API, we also can get benefit especially to people not familiar with the code. Compared with the original design Current design is simple and the code is more easy to be understood and easy to maintain.

[Kim] I'm sorry, but I cannot fully agree on this. Of course I agree the bluez-lib will help to decrease workload for bluez upgrade, but I don't think it is so big impact as you said (4 times more efficient).

· Stabilization

[Martin] we spend a lot of efforts to pass the TCT, and you know, according to our last f2f meeting, pass TCT test is the stabilization criteria requirement from Samsung. In fact we have done a lot of test on it. So if you think that is not enough, please let us know what other test your want us to pass?

[Kim] TCT is the mandatory requirement to be on Tizen. Even if passing TCT, we cannot tell it is really stablized code. Except for TCT, we need to consider many test scenarios for mobile, IVI, wearable, TV, etc. In my opinion, the stablization is very important work, but requires extremely long time. I cannot tell you exactly it is really stablized code or not, but there are some methods to prove its stablization. One of them is PTS test. Other than this, Samsung has a lot of internal processes to prove its stablization. Anyway, I think we need to consider this issue more deeply.

Summary:

[Martin]I believe NTB is a good design and can help improve the Tizen Bluetooth framework from many aspect, like memory consumption, maintain efforts, and unified interface.

At same time we are open to any suggestion and proposal as well as patches, since it is purely an open source project. besides, I think we may meet some issues when integrate that into Tizen-3.0 and Tizen-2.x. We will actively work on any issues. if you met any issues, please let us know.

And the NTB develop work is still ongoing, we just finished the main features, and pass the TCT test, now we are work with Dominique’s team to add multi-user support and integrate NTB into Tizen-3.0. And besides, the next stage work is in also in plan, like memory consumption optimization work, and other potential new features.

[Kim] I don't mean to say the NTB is totally wrong. I just intend to solve several doubts of the NTB.

For the CAPI issue, I wish to recieve your reply and discuss it again.

For the memory efficiency issue, it can be discussed later after removing gobject and enabling memory optimization. Other than those, I'd like to learn memory efficiency in architectural aspect.

For the maintaining effort, I will also reconsider your opinion by myself. If possible, objective material can be of help to prove this issue.

For the stablization, PTS test is recommanded to prove it. Let's think about methods more deeply to prove the stablization other than PTS.

We really need the your input and feedback on NTB, that is really important to our work.

Lastly, according to your feedback, below work already started.

1. “Error and Exception Handling fix”. It will be finished within two weeks

2. “Runtime plugin and module load/unload” it will be finished within two weeks

[Kim] Thank you very much for reconsidering these issues. :)

Regards,

Seungku

김 승구(Seungku Kim)

Engineer

S/W Platform Team

Software R&D Center
SAMSUNG ELECTRONICS CO.,LTD

Mobile : +82-10-9312-9358
E-Mail : [email protected]

------- Original Message -------

Sender : Xu, Martin<[email protected]>

Date : 2014-10-29 17:24 (GMT+09:00)

Title : RE: [Dev] [Bluetooth] About NBT

Hi Kim:

Thank you very much for carefully investigate on NTB, and give out the valuable feedback.

I think it is a very good technical discussion. We are very glad talk on it.

Let’s go through these topics one by one.

[Martin]Yes, you are right, NTB is using shared library, and shared library can’t share section between different process.

But I do not think it is a problem here.

Firstly, our design philosophy is to provide all Bluetooth service through unified Tizen Core API interface, I think that is also the overall design requirement from Tizen.

But I am still keep open on this topic, if you still think it is a issue, please give me more examples, we can continue to discuss on it. J

· Error and Exception Handling

[Martin]we already start to work on it. Thanks for your input.

· memory consumption design goal. The memory consumption of current bluetooth-frwk is a result when hfp/share was enabled, but I think the new design did not enable them.

[Martin] I believe we can reach the design goal in the end.

Thank you very much for pointing out the runtime load module and plugin, that is the missed implementation in the design, we will work on it.

· Reduce maintaining efforts

· Stabilization

Summary:

[Martin]I believe NTB is a good design and can help improve the Tizen Bluetooth framework from many aspect, like memory consumption, maintain efforts, and unified interface.

We really need the your input and feedback on NTB, that is really important to our work.

Lastly, according to your feedback, below work already started.

1. “Error and Exception Handling fix”. It will be finished within two weeks

2. “Runtime plugin and module load/unload” it will be finished within two weeks

I hope that can answer your question, any issues, please let me know. J

Thanks!

From: Xu, Martin
Sent: Wednesday, October 29, 2014 14:19
To: Zheng, Wu
Subject: RE: [Dev] [Bluetooth] About NBT

Hi Kim:

Thank you very much for carefully investigate on NTB, and give out the valuable feedback. J

But I think it should not be the “issue” at all, instead, it should be the purely technical and design discussion. In fact, in the past year, Samsung Comms team, Intel comms team have already a lot of discuss on it.

I still very happy to answer your questions, Let’s go through your issues one by one.

[Martin]Yes, you are right, NTB is using shared library, and shared library can’t share section between different process.

But I do not think it is an issue here.

Firstly, our design philosophy is to provide all Bluetooth service through unified Tizen Core API interface, I think that is also the overall design requirement from Tizen.

But I am still keep open on this issue, if you still think it is a issue, please give me more examples, we can continue to discuss on it.

· Error and Exception Handling

[Martin]we already start to work on it. Thanks for your input.

· memory consumption design goal

The memory consumption of current bluetooth-frwk is a result when hfp/share was enabled, but I think the new design did not enable them.

[Martin] I believe we can reach the design goal in the end.

But the expectation is reasonable, we did not enable HFP, but at the prototype, we also do nothing on the memory consumption optimization, as I mentioned before, we used gobject which will consume a lot of memory. Removing gobject and other memory consumption optimize work will be done in next stage. After all of the work be done, I believe we definitely will reach the goal. J

Thank you very much for pointing out the runtime load module and plugin, that is the missed implementation in the design, we will work on it.

· Reduce maintaining efforts

[martin] I believe, both of us agree that this design will make the big version upgrade very easy, after we introduce the bluez-lib design, all the work will focus on very limited files. I’d like to emphasize that we can’t expect that there will no big change anymore. Upstream always claim to keep stable of API, but they always kept changing the API. Besides, even the small change of BlueZ API, we also can get benefit especially to people just access the code. In the original design all the BlueZ will go through Bluetooth-service and Bluetooth-service then call the blueZ, and the code is difficult to understand, and difficult to debug and difficult maintain.

· Stabilization

[Martin] we spend a lot of efforts to pass the TCT, and you know, according to last f2f meeting, pass TCT test is the stabilization criteria requirement from Samsung. So if you think that is not enough, please let us know what else test your want us to pass?

Summary:

I believe NTB has resolved a lot of issues in old design, please _do_ not just focus on some specific design expectation data, please have a look at the design and implementation itself. J

Besides, I believe, when integrate it into Tizen-2.x especially add some Tizen-2.x features, will definitely meet some issues. Just like we adding multi-user support when integrate it into Tizne-3.0. So I am very happy to help you on it. if you have any issues, please let us know.

Thanks!

From: Xu, Martin
Sent: Wednesday, October 29, 2014 14:12
To: Zheng, Wu
Subject: RE: [Dev] [Bluetooth] About NBT

om: Dev [mailto:[email protected]] On Behalf Of ???
Sent: Monday, October 27, 2014 7:50
To: Dominig Ar Foll
Cc: [email protected]
Subject: Re: [Dev] [Bluetooth] About NBT

Hi Mr. Doming ar Foll,

I'm not proposing something for NBT.

I shared these issues with Mr. Zheng before, but he didn't agree on these issues.

So, I'm sharing the issues in here and expecting to get your opinion.

Regards,

Seungku Kim

------- Original Message -------

Sender : Dominig Ar Foll<[email protected]>

Date : 2014-10-26 08:42 (GMT+09:00)

Title : Re: [Dev] [Bluetooth] About NBT

Kim,

interesting report.

Could you please let us know what you have proposed to Zheng ?

As your chat were private so far, it's not easy to see how we can help.

BT-NG has announced the integration of Multi user support last week and for that reason is of high interest for Tizen 3, nevertheless it also has to work well for all usages in Tizen 3.

Regards

2014-10-24 7:05 GMT+02:00 김승구 <[email protected]>:

Dear all,

I'm raising some issues about NBT (Next-generation Bluetooth).

Please find an attached file.

I and Mr. Zheng Wu have already discussed about these issues, but we couldn't find common ground for these.

Please give any idea of this issue reporting.

You can see concept of NBT at the below link and code of NBT at "devel" branch of bluetooth-frwk.

https://wiki.tizen.org/wiki/NTB_Architecture

* Issue summary

1. CAPI implementation problems

2. Error and exception handling

3. NBT's expected performance

Regards,

Seungku Kim

_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

--
Dominig ar Foll
Senior Software Architect
Intel Open Source Technology Centre

_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Re: [Dev] [Bluetooth] About NBT

Reply via email to