On Wed, Apr 10, 2013 at 10:05 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
>> +struct pincb_iter {
>> + GSList *it; /* current callback function */
>> + int count; /* numer of times it() was called */
>> + /* When the iterator reaches the end, it is NULL and count is -1 */
>> +};
>
> explain to me why this iter struct is needed. I am a little bit lost on the nested GSList in it.
>
> I get the basic idea what this patch tries to achieve, but it looks a bit too complicated to me.
The struct pincb_iter is an iterator object over the list of pincodes
dinamically generated by the pincode callbacks stored in the adapter.
This list of callbacks is a GSList * that lives in the adapter. To
iterate once every element of the list, we could use a GSList * and
->next, but this will iterate once every callback. Before, the
callbacks were generating only one code, but now I want a plugin to be
able to generate more than one pincode (calling the callback several
times).
So, what I need is a pincode iterator (not a callback iterator). This
struct pincb_iter has an iterator to the callbacks list (it) and an
integer representing how many times was the function called. Then it
implements the function pincb_iter_next() that will give you the next
pincode generated by the list of plugin callbacks handling all the
logic of calling several times the same function or moving to the next
function if there aren't more codes for that one.
So you create a fresh new iterator and call pincb_iter_next on it
until you get a 0, which means that there no more codes to provide.
You know you reached the end when you ask for the next and you get 0,
but you can't predict if you will get a 0 before calling it (its more
like a python iterator rather than a c++ iterator).
The reason why I need to store a struct pincb_iter* in the struct
bonding_req is because the iterator is implemented in adapter.c but it
is stored in device.c. Moving its implementation to device.c creates
more problems, and after all the iterator is over the adapter's list
of plugin callbacks... But there's no nested GSList * on it. The
GSList * is just a GSList iterator, not a new list.
Hope it helps.
Best regards,
Alex.
--
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
