On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
<mche...@infradead.org> wrote:
> We shouldn't write API's thinking on some specific use case or aplication.
> If there's a problem with zap, the fix should be there, not at the kernel.

Your response suggests I must have poorly described the problem.  Zap
is just one example where having an "inconsistent" view of the various
performance counters is easily visible.  If you're trying to write
something like an application to control antenna orientation, the fact
that you cannot ask for a single view of all counters can be a real
problem.  Having to make separate ioctl calls for each field can cause
real problems here.

I disagree strongly with your assertion that we should not considering
specific use cases when writing an API.  That's *EXACTLY* what you
want to do - when designing an API, you should be asking yourself what
use cases is it actually going to be used for, and strive to build an
API that accommodates all the use cases.  In this case, Manu's
approach provides the ability to get a single consistent view of all
the counters (for those drivers which can support it), which solves a
specific use case that cannot be accomplished with the existing API.
Building abstract APIs without considering all use cases is how we end
up with APIs that nobody uses because they don't actually work in the
real world.

The fact that the existing SNR and strength counters never had their
format explicitly defined is a really good example of how nobody must
have considered how applications would be expected to actually use the
API and represent the information to users in a useful manner.

On the other hand, this issue has been beaten to death so badly and
the existing API has been broken/useless for so long that I have
lowered my expectations to the point where I would accept just about
*any* proposal that actually provides a uniform representation of SNR
across drivers.

(/rant mode off)

> Also, the above mentioned problem can happen even if there's just one API
> call from userspace to kernel or if the driver needs to do separate,
> serialized calls to firmware (or a serialized calculus) to get the
> three measures.

True, the accuracy in which a given driver can provide accurate data
is tied to the quality of the hardware implementation.  However, for
well engineered hardware, Manu's proposed API affords the ability to
accurately report a consistent view of the information.  The existing
implementation restricts all drivers to working as well as the
worst-case hardware implementation.

>> For what it's worth, we have solved this problem in hwmon driver the
>> following way: we cache related values (read from the same register or
>> set of registers) for ~1 second. When user-space requests the
>> information, if the cache is fresh it is used, otherwise the cache is
>> first refreshed. That way we ensure that data returned to nearby
>> user-space calls are taken from the same original register value. One
>> advantage is that we thus did not have to map the API to the hardware
>> register constraints and thus have the guarantee that all hardware
>> designs fit.
>> I don't know if a similar logic would help for DVB.
> This could be an alternative, if implemented at the right way. However,
> I suspect that it would be better to do such things at libdvb.
> For example, caching measures for 1 second may be too much, if userspace is
> doing a scan, while, when streaming, this timeout can be fine.

Jean's caching approach for hwmon is fine for something like the
chassis temperature, which doesn't change that rapidly.  However, it's
probably not appropriate for things like SNR and strength counters,
where near real-time feedback can be useful in things like controlling
a rotor.

One more point worth noting - the approach of returning all the
counters in one ioctl can actually be cheaper in terms of the number
of register read operations.  I've seen a number of drivers where we
hit the same register three or four times, since all of various fields
are based on the same register.  Having a single call actually allows
all the duplicate register reads to be eliminated in those cases, the
driver reads the register once and then populates all the fields in
one shot based on the result.

I was actually against Manu's proposal the last time it was put out
there, as I felt just normalizing the existing API would be *good
enough* for the vast majority of applications.  However, if we have
decided to give up on the existing API entirely and write a whole new
API, we might as well do it right this time and build an API that
satisfies all the people who plan to make use of it.


Devin J. Heitmueller - Kernel Labs
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to