Re: [RFC][PATCH v2 3/7] NFC: add nfc generic netlink interface

[Samuel Ortiz <sameo@linux.intel.com>]

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/