All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Hanisch <dvb@cinnamon-sage.de>
To: Mike Isely <isely@isely.net>
Cc: hermann pitton <hermann-pitton@arcor.de>,
	Hans Verkuil <hverkuil@xs4all.nl>,
	linux-media@vger.kernel.org
Subject: Re: RFC: exposing controls in sysfs
Date: Thu, 08 Apr 2010 19:57:58 +0200	[thread overview]
Message-ID: <4BBE1926.1010207@cinnamon-sage.de> (raw)
In-Reply-To: <alpine.DEB.1.10.1004071939510.5518@ivanova.isely.net>

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
>

      parent reply	other threads:[~2010-04-08 17:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-05 21:47 RFC: exposing controls in sysfs Hans Verkuil
2010-04-05 22:12 ` Hans Verkuil
2010-04-06  6:37   ` Hans Verkuil
2010-04-06 11:06     ` Andy Walls
2010-04-06 11:27       ` Laurent Pinchart
2010-04-06 11:44         ` Markus Rechberger
2010-04-06 15:08           ` Mike Isely
2010-04-06 15:16         ` Mike Isely
2010-04-06 22:39           ` Hans Verkuil
2010-04-07  2:10             ` hermann pitton
2010-04-07  6:56             ` Hans Verkuil
2010-04-08  0:52               ` Mike Isely
2010-04-06 13:16     ` Mauro Carvalho Chehab
2010-04-06 13:44       ` Hans Verkuil
2010-04-06 13:59         ` Devin Heitmueller
2010-04-06 15:05           ` Mike Isely
2010-04-06 14:32         ` Mauro Carvalho Chehab
2010-04-06 16:06           ` Jonathan Cameron
2010-04-06 16:36             ` Bjørn Forsman
2010-04-06 14:41   ` Mike Isely
2010-04-06 16:19     ` Jonathan Cameron
2010-04-06 22:47       ` Hans Verkuil
2010-04-06 14:33 ` Mike Isely
2010-04-07 18:50   ` Lars Hanisch
2010-04-07 22:15     ` hermann pitton
2010-04-08  0:47       ` Mike Isely
2010-04-08  0:58         ` Mike Isely
2010-04-08 17:57         ` Lars Hanisch [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BBE1926.1010207@cinnamon-sage.de \
    --to=dvb@cinnamon-sage.de \
    --cc=hermann-pitton@arcor.de \
    --cc=hverkuil@xs4all.nl \
    --cc=isely@isely.net \
    --cc=linux-media@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.