Am 08.04.2010 02:47, schrieb Mike Isely:
On Thu, 8 Apr 2010, hermann pitton wrote:
Hi,
Am Mittwoch, den 07.04.2010, 20:50 +0200 schrieb Lars Hanisch:
Am 06.04.2010 16:33, schrieb Mike Isely:
[snip]
Mike, do you know of anyone actively using that additional information?
Yes.
The VDR project at one time implemented a plugin to directly interface
to the pvrusb2 driver in this manner. I do not know if it is still
being used since I don't maintain that plugin.
Just FYI:
The PVR USB2 device is now handled by the pvrinput-plugin, which uses only ioctls. The "old" pvrusb2-plugin is obsolete.
http://projects.vdr-developer.org/projects/show/plg-pvrinput
Lars:
Thanks for letting me know about that - until this message I had no idea
if VDR was still using that interface.
Regards,
Lars.
[snip]
thanks Lars.
Mike is really caring and went out for even any most obscure tuner bit
to help to improve such stuff in the past, when we have been without any
data sheets.
Hermann:
You might have me confused with Mike Krufky there - he's the one who did
so much of the tuner driver overhauling in v4l-dvb in the past.
To open second, maybe third and even forth ways for apps to use a
device, likely going out of sync soon, does only load maintenance work
without real gain.
Well it was an experiment at the time to see how well such a concept
would work. I had done it in a way to minimize maintenance load going
forward. On both counts I feel the interface actually has done very
well, nonstandard though it may be.
I still get the general impression that the user community really has
liked the sysfs interface, but the developers never really got very fond
of it :-(
From my point of view as an application developer I never tried to use
sysfs at all. I admit that it's nice to use from a shell script in "known
environments" (like setting up a card for recording with cat etc.) but what
about error handling? How will I (the script) know, if setting a control is
successful or not? Currently I don't know if v4l2-ctl returns some useful
exit code, but with ioctls it's a lot easier to track errors.
I never liked to handle with directories and files, reading and writing if
there's a function which is doing the same thing in a much easier way. :-)
But all this might be related to my not-really-present knowledge of using
sysfs in the right way.
And reading other posts debugfs seems to be the better choice (just read
some articles on it to get a general survey of it).
Regards,
Lars.
We should stay sharp to discover something others don't want to let us
know about. All other ideas about markets are illusions. Or?
So, debugfs sounds much better than sysfs for my taste.
Any app and any driver, going out of sync on the latter, will remind us
that backward compat _must always be guaranteed_ ...
Or did change anything on that and is sysfs excluded from that rule?
Backwards compatibility is very important and thus any kind of new
interface deserves a lot of forethought to ensure that choices are made
in the present that people will regret in the future. Making an
interface self-describing is one way that helps with compatibility: if
the app can discover on its own how to use the interface then it can
adapt to interface changes in the future. I think a lot of people get
their brains so wrapped around the "ioctl-way" of doing things and then
they try to map that concept into a sysfs-like (or debugfs-like)
abstraction that they don't see how to naturally take advantage of what
is possible there.
-Mike
--
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
