Am 08.12.09 10:16, schrieb Julian Scheel:
Hello together,
after the last thread which asked about signal statistics details
degenerated into a discussion about the technical possibilites for
implementing an entirely new API, which lead to nothing so far, I
wanted to open a new thread to bring this forward. Maybe some more
people can give their votes for the different options
Actually Manu did propose a new API for fetching enhanced statistics.
It uses new IOCTL to directly fetch the statistical data in one go
from the frontend. This propose was so far rejected by Mauro who wants
to use the S2API get/set calls instead.
Now to give everyone a quick overview about the advantages and
disadvantages of both approaches I will try to summarize it up:
1st approach: Introduce new IOCTL
Pros:
- Allows a quick fetch of the entire dataset, which ensures that:
1. all values are fetched in one go (as long as possible) from the
frontend, so that they can be treated as one united and be valued in
conjunction
2. the requested values arrive the caller in an almost constant
timeframe, as the ioctl is directly executed by the driver
- It does not interfere with the existing statistics API, which has to
be kept alive as it is in use for a long time already. (unifying it's
data is not the approach of this new API)
Cons:
- Forces the application developers to interact with two APIs. The
S2API for tuning on the one hand and the Statistics API for reading
signal values on the other hand.
2nd approach: Set up S2API calls for reading statistics
Pros:
- Continous unification of the linuxtv API, allowing all calls to be
made through one API. -> easy for application developers
Cons:
- Due to the key/value pairs used for S2API getters the statistical
values can't be read as a unique block, so we loose the guarantee,
that all of the values can be treatend as one unit expressing the
signals state at a concrete time.
- Due to the general architecture of the S2API the delay between
requesting and receiving the actual data could become too big to allow
realtime interpretation of the data (as it is needed for applications
like satellite finders, etc.)
I hope that this summary is technically correct in all points, if not
I'd be thankful for objective corrections. I am not going to
articulate my personal opinion in this mail, but I will do it in
another mail in reply to this one, so that this mail can be seen as a
neutral summary of the current situation.
So now it's everyones turn to think about the options and give an
opinion. In the end I am quite sure that all of us would have great
benefits of an improved statistics API.
Cheers,
Julian
--
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
The above mail of course has nothing to do with USB-Statistics. I must
have been slightly confused when typing the message title! Sorry for that!
--
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
