On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> wrote: > I don't like the idea of creating structs grouping those parameters. While for > certain devices this may mean a more direct approach, for others, this may > not make sense, due to the way their API's were implemented (for example, > devices with firmware may need several calls to get all those info). There is some value in providing grouping the results in a single request - in many cases the data is based off of the same internal registers, and Manu's proposed approach allows for a more "atomic" response. The fact that we currently do the status, SNR, strength, and UNC/BER in separate calls is one reason that people sometimes see inconsistent results in the output of tools like zap. As an example, they can see lines in the zap output where the lock is lost but SNR appears fine. In the case where the driver servicing the query needs to do three calls, it could be slightly more expensive, but only if we believe that it is commonplace to ask for a subset of the stats. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
