On Wed, Jun 22, 2011 at 03:08:06PM +0200, Johannes Berg wrote: > On Wed, 2011-06-22 at 14:57 +0200, Samuel Ortiz wrote: > > > > And this looks like an array. Do you really want to do that? That means > > > lots of reallocations. > > > So NFC polling is a bit weird. Whenever you start polling for passive targets, > > the polling results are minimal: You only know that there is _a_ target on a > > particular frequency/modulation. It could be the same as the one you got 5 > > minutes ago, or not. To verify it, you'd need to select the target (and put > > all other ones on standby) and start sending specific commands to it (Of > > course, you have a different set of commands per target family...). Only then > > you _may_ read some sort of UID that could help you matching targets from your > > previous poll cycle. > > My point is, when we start polling, we will invalidate all existing targets > > anyway. So a linked list or an array won't make a big difference in that area. > > So basically you're saying that you basically get everything at the same > time so you really throw away the old list/array and re-create it. Basically, yes. And trying to check which parts of the old list is still there is quite expensive. > But from a driver POV, does it really know the number of targets? It does. From the NFC HW I got access to, it's either one single target, or at most one per rf band. And in that case the driver can know if there is or not a target on a specific band. > Anyway, all this doesn't matter since it's purely internal, and the > userspace APIs no longer have this limitation, so if this turns out an > issue at some point internal refactoring can easily fix it :-) That's certainly true. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
