Re: [RFC 1/3] adapter-api: Add Experimental property

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

 



Hi Luiz,

>>> This adds Experimental property which indicates what experimental
>>> features are currently enabled.
>>> ---
>>> doc/adapter-api.txt | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>> 
>>> diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
>>> index 464434a81..13e904425 100644
>>> --- a/doc/adapter-api.txt
>>> +++ b/doc/adapter-api.txt
>>> @@ -335,3 +335,8 @@ Properties        string Address [readonly]
>>>                              "peripheral": Supports the peripheral role.
>>>                              "central-peripheral": Supports both roles
>>>                                                    concurrently.
>>> +
>>> +             array{string} Experimental [readonly, optional]
>>> +
>>> +                     List of 128-bit UUIDs that represents the experimental
>>> +                     features currently enabled.
>> 
>> I wonder if this is the best name.
>> 
>> Do we care about just the enabled experimental features or the overall supported experimental features as well. And please keep in mind that we also have per-adapter vs global experimental features. So we should distinguish here as well.
> 
> This is per-adapter and I guess the global one would could exposed on
> all adapters since we don't have a global object, or perhaps you are
> suggesting to use / for that?

if it is read-only, then yes, the global one could be exposed on all adapters.

>> We also need to document that this property is only available if bluetoothd is started with -E and otherwise this property is omitted.
> 
> Will add it.
> 
>> My proposal would be to at least name it ExperimentalSupport or ExperimentalFeatures to give us a path to nicely extend it if needed.
> 
> Sure, I do wonder if we should make it writable as well, so
> applications can enable/disable experimental features themselves? Or
> perhaps that is going too far as to enable unstable code by
> application, it would only work when -E is given thought which would
> enable everything anyway but I was thinking on having -E optionally
> take a list of UUIDs so one could enable just certain features
> instead.

Lets not make this writeable from applications. Some of them require power off etc. So that is going to far.

Regards

Marcel




[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