Hi Alex,
>>> +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.
I still get the feeling this is too heavy weight compared to what we are trying to do. Not that I have a better idea right on how to achieve what you need.
Johan, any ideas?
Regards
Marcel
--
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
