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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
