Re: [RFC] Attribute IO Driver

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

 



Hi,

On Mon, Jun 20, 2011 at 3:56 PM, Anderson Lizardo
<anderson.lizardo@xxxxxxxxxxxxx> wrote:
> Hi,
>
> On Mon, Jun 20, 2011 at 8:35 AM, Claudio Takahasi
> <claudio.takahasi@xxxxxxxxxxxxx> wrote:
>> This is the current driver definition:
>> struct btd_attio_driver {
>>        const char *name;
>>        const char **uuids; /* UUIDs of primary services */
>>        int (*probe) (struct btd_device *device, GSList *uuids);   /*
>> List of Primary Services: UUID and start/end handles */
>>        void (*remove) (struct btd_device *device);
>>        int (*connected) (struct btd_device *device, GAttrib *attrib);
>>        void (*disconnected) (struct btd_device *device);
>> };
>>
>> * Open issues:
>> 1. How to request re-connections. The current code shares the GAtrrib,
>> I am trying to avoid sharing the GAttrib reference creating a ATT
>> command queue. The idea is to inform the queue when the device is
>> probed, allowing offline operations and automatic connection request.
>> If there is at least one item in the queue the device will be added in
>> the "automatic" connection list. Using a command queue, it MAY be
>> possible to remove the "connected" and "disconnected" callbacks.
>> 2. Move attio.c source to device.c?
>> 3. should Generic API be a "built-in" ATT IO driver? (I moved to
>> plugins/attribute.c), it looks more clean to me. Same "level" of
>> Service/SDP plugin.
>> 4. Passive scanning: it will be necessary to re-connect
>
> Just to complement the list of open issues:
>
> 5. We plan to drop the connected/disconnected callbacks. Most profiles
> (except proximity) will not need them, and as Claudio mentioned, we do
> not want to tie the profiles to an active connection. For those who
> need a handler for connected/disconnected events, we can implement a
> "btd_adapter_register_connected_callback" (just like the existing
> btd_adapter_register_powered_callback() in src/adapter.c).

The most obvious question, which I didn't see any answer here, is why
we need to separate the Device drivers from the ATT IO drivers? Why
can't we just extend the Device drivers to attend the LE profiles?

-- 
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