Return-Path: Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [PATCH 1/6] core: Convert the pincode callback to an interable list. From: Marcel Holtmann In-Reply-To: Date: Thu, 11 Apr 2013 10:11:21 -0700 Cc: linux-bluetooth Message-Id: <55B42A4A-61A0-4AE4-AC7A-389E20FFAFB7@holtmann.org> References: <1365628753-16774-1-git-send-email-deymo@chromium.org> <1365628753-16774-2-git-send-email-deymo@chromium.org> To: Alex Deymo Sender: linux-bluetooth-owner@vger.kernel.org List-ID: 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