Return-Path: MIME-Version: 1.0 In-Reply-To: References: <1365628753-16774-1-git-send-email-deymo@chromium.org> <1365628753-16774-2-git-send-email-deymo@chromium.org> From: Alex Deymo Date: Thu, 11 Apr 2013 09:53:42 -0700 Message-ID: Subject: Re: [PATCH 1/6] core: Convert the pincode callback to an interable list. To: Marcel Holtmann Cc: linux-bluetooth Content-Type: text/plain; charset=ISO-8859-1 List-ID: On Wed, Apr 10, 2013 at 10:05 PM, Marcel Holtmann 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.