Hi, >> We encountered the same dilemma and suggested a solution using Flow >> specification. >> >> The Flow Specification HCI relates to an ACL handle and not a specific >> L2CAP channel. If we intend to configure the Flow Spec using socket >> option then different profiles might overrun each other settings. >> >> The other option of using the mgmt is not too good either. Since this >> command is "Link" related and not "Adapter/Device" related, the daemon >> dbus API would have to receive the ACL handle as parameter or introduce >> a new property on Device node which might not exist. Note that one can >> create an L2CAP socket without interfacing the daemon. >> >> My humble opinion is to set the Flow Spec per socket (l2cap/rfcomm) >> using socket options. Store it per channel and send accumulated flow >> spec on every change per ACL. >> >> - channel changed its flow sepc >> - channel with flow spec was closed >> >> All done in the kernel, no changes to the daemon. >> >> Kind Regards, >> Amir Hadar >> >> > > Thanks for your valuable inputs; as mentioned earlier please note we are > currently using Android Froyo (2.2.2) which has bluez version 4.47 & > kernel version 2.6.32. > > Using Flow specification is seems to be good. I will change it to flow spec > instead of qos setup command. > > I want to know one thing if we want to use setsockopt to send flow spec > (add new socket option SO_L2CAP_OQOS) just handle it l2cap.c to send hci > flow spec command, > that's what you are suggesting? > First as said before you must submit your patch based on latest bluetooth-next kernel (not on 2.6.32). Second, You should get acceptance on adding new socket option. As I remember there was an objection on adding new socket options though in this case I think it is the correct solution. Here is a short RFC I would suggest to store the flow spec parameters in the l2cap_chan struct. Store the current active flow spec (also add pending_flow_spec) in the hci_conn struct. In hci_connect after the acl is connected call a new function hci_calc_flow_spec which goes over all l2cap channel (hci_chan->list) and accumulate flow spec params. Set the hci_conn pending flow spec and send the HCI cmd. In hci_event add case for the command complete and a "cs" function for handling the response. In this function set the active flow spec. When an l2cap channel disconnect and the ACL is still active you should call the hci_calc_flow_spec again to accumulate the params for the rest of l2cap channels connected. (You should work out the details). BTW, The flow spec params in the hci_conn and l2cap_chan can help us in the future in building trafic shaping on the hci_sched_acl. Amir -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
