Re: [RFC v3] doc: Connection Parameters command and event

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Marcel, Johan, Andre,

On Tue, Apr 8, 2014 at 5:35 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> Hi Johan,
>
>>>> +Load Connection Parameters Command
>>>> +====================================
>>>> +
>>>> +   Command Code:           0x0031
>>>> +   Controller Index:       <controller id>
>>>> +   Command Parameters:     Params_Count (2 Octets)
>>>
>>>                              Param_Count
>>>
>>>> +                           Params1 {
>>>
>>>                              Param1
>>>> +                                   Address (6 Octets)
>>>> +                                   Address_Type (1 Octet)
>>>> +                                   Min_Connection_Interval (2 Octets)
>>>> +                                   Max_Connection_Interval (2 Octes)
>>>> +                                   Connection_Latency (2 Octets)
>>>> +                                   Supervision_Timeout (2 Octets)
>>>> +                           }
>>>> +                           Params2 {  }

Regarding the parameters it seems we should include the scan interval
and window as well otherwise the logic will not be completely in the
kernel and the userspace will still have to keep a list of devices and
set the scan parameters by itself. IMO it would be better the leave
the kernel to control everything, anyway it will have to deal with
scanning logic based on connection list, so it will be able to detect
if a certain connection requires a more aggressive scanning and also
relax the scanning once connected.

>>>                              Param2
>>>
>>> It should be loading multiple sets of parameter. The specification
>>> also talks about Connection Parameter as in singular set.
>>
>> This would be very funny sounding English imo. The specification only
>> uses singular for the HCI Commands and Event (where "Connection
>> Parameter Request" does sound ok and doesn't mean that we're dealing
>> with a single parameter). In the command and event descriptions the spec
>> is pretty clear that we're dealing with multiple parameters, e.g.:
>>
>> (from 7.8.31):
>>       "This indicates that the Host has accepted the remote device’s
>>       request to change connection parameters."
>>
>>       "The Interval_Min parameter shall not be greater than the
>>       Interval_Max parameter"
>>
>>       "The Timeout parameter shall..."o
>>
>> (from 7.8.32):
>>       "This indicates that the Host has rejected the remote device’s
>>       request to change connection parameters."
>>
>> (from 7.7.65.6):
>>       "This event indicates to the master’s Host or the slave’s Host
>>       that the remote device is requesting a change in the connection
>>       parameters."
>>
>> So imo the spec is pretty clear that we're dealing with multiple
>> parameters per device.
>>
>>
>>>> +New Connection Parameters Event
>>>
>>>              Parameter
>>
>> Nope. We're notifying user space of a new set of multiple parameters.
>> Using the singular form here makes this sound quite funny. If you had
>> just one parameter then we wouldn't even name the event like this but
>> directly spell out which parameter is in question (e.g. "New Connection
>> Latency Event").
>>
>> If you don't believe me feel free to get another opinion from a native
>> English speaker ;)
>
> all of our commands are containing multiple parameters, but I do not like the wording of making it all plural. The notification event should be singular and the loading command should be plural. For me it is always a set of multiple individual parameters that make up the command and event.

I would suggest to name it Load Connections Command and rename
Params_Count to Connection_Count, Param1 to Connection1, etc,
basically drop the term parameter and use connection as a set of
parameters.

-- 
Luiz Augusto von Dentz
--
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




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux