public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Oberritter <obi@linuxtv.org>
To: Issa Gorissen <flop.m@usa.net>
Cc: Ralph Metzler <rjkm@metzlerbros.de>, linux-media@vger.kernel.org
Subject: Re: [PATCH] Ngene cam device name
Date: Sat, 12 Mar 2011 15:58:15 +0100	[thread overview]
Message-ID: <4D7B8A07.70602@linuxtv.org> (raw)
In-Reply-To: <777PcLohh6368S03.1299940473@web03.cms.usa.net>

On 03/12/2011 03:34 PM, Issa Gorissen wrote:
> From: Ralph Metzler <rjkm@metzlerbros.de>
>> Andreas Oberritter writes:
>>  > > Unless you want to move the writing to/reading from the CI module into
>>  > > ioctls of the ci device you need another node. 
>>  > > Even nicer would be having the control messages moved to ioctls and
> the
>>  > > TS IO in read/write of ci, but this would break the old interface.
>>  > 
>>  > It's possible to keep compatibility. Just add ioctls to get and set the
>>  > interface version. Default to the current version, not supporting TS
>>  > I/O. If the version is set to e.g. 1, switch from the current interface
>>  > to the new one, using ioctls for control messages.
>>
>> A possibility, but also requires rewrites in existing software like
> libdvben50221.
>> Right now you can e.g. tune with /dev/dvb/adapter0/frontend0, point an
> unchanged
>> libdvben50221 to /dev/dvb/adapter1/ci0 (separate adapter since it can even
>> be on a different card) and pipe all PIDs of cam_pmt of the program
>> you are watching through /dev/dvb/adapter1/sec0(cam0) and it is decoded.

Obviously, adapting libdvben50221 would be the first thing to do for an
enhanced CI API. Probably not a big deal.

> This is KISS compliant by the way.
> 
> Andreas, please explain what *really* bothers you with this architecture
> choice of having a new node, leaving the current API as is.

I'm not against adding a new node if its behaviour is well defined and
documented and if it integrates well into the existing API.

> You might find that adding a new node is lazy, but there are advantages:
> - current API isn't broken, namely, ca devices are still used for the control
> messages, nothing more;

"nothing more" is wrong, as ca devices are used for descramblers, too.

> - for applications using the DVB API, it is also easier to debug while reading
> the code, in my opinion, because of the usage of two distinct devices (ca /
> cam) instead of one (ca / ioctls);

That's just a matter of taste.

Regards,
Andreas

  reply	other threads:[~2011-03-12 14:58 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-12 14:34 [PATCH] Ngene cam device name Issa Gorissen
2011-03-12 14:58 ` Andreas Oberritter [this message]
2011-03-28  0:44   ` Ralph Metzler
2011-03-28 21:40     ` Mauro Carvalho Chehab
2011-04-24  9:31       ` Issa Gorissen
2011-03-28 22:57     ` Oliver Endriss
2011-04-05 21:50       ` Issa Gorissen
  -- strict thread matches above, loose matches on Subject: below --
2011-05-06 18:29 Issa Gorissen
2011-05-08  9:53 ` Andreas Oberritter
2011-05-08 10:30   ` Issa Gorissen
2011-05-06 13:47 Issa Gorissen
2011-05-06 16:07 ` Andreas Oberritter
2011-05-04 14:51 Issa Gorissen
2011-05-04 14:05 Issa Gorissen
2011-05-04 14:27 ` Andreas Oberritter
2011-05-04 11:09 Issa Gorissen
2011-05-04 11:07 Issa Gorissen
2011-05-04 13:51 ` Andreas Oberritter
2011-05-04  8:27 Issa Gorissen
2011-05-04  9:59 ` Andreas Oberritter
2011-05-04 11:20   ` Ralph Metzler
2011-05-04 12:30     ` Andreas Oberritter
2011-05-04 13:15       ` Ralph Metzler
2011-05-04 13:35       ` Martin Vidovic
2011-05-04 14:46         ` Andreas Oberritter
2011-05-05 14:43           ` Martin Vidovic
2011-05-06 12:17             ` Andreas Oberritter
2011-05-06 13:43               ` Walter Van Eetvelt
2011-05-08 10:05               ` Martin Vidovic
2011-05-08 17:58                 ` Andreas Oberritter
2011-05-08 23:55                   ` Martin Vidovic
2011-05-09 11:44                     ` Andreas Oberritter
2011-04-24 11:38 Issa Gorissen
2011-05-03 23:11 ` Mauro Carvalho Chehab
2011-05-04  7:24   ` Andreas Oberritter
2011-03-12 15:39 Issa Gorissen
2011-03-12 14:10 Issa Gorissen
2011-03-12 14:48 ` Andreas Oberritter
2011-03-12 14:57   ` Martin Vidovic
2011-03-12 15:06     ` Andreas Oberritter
2011-03-11 18:33 Issa Gorissen
2011-03-11 20:39 ` Andreas Oberritter
2011-03-11 21:46   ` Ralph Metzler
2011-03-12 13:25     ` Andreas Oberritter
2011-03-12 13:55       ` Ralph Metzler
2011-03-10 15:29 Issa Gorissen
2011-03-11 15:52 ` Andreas Oberritter
2011-03-11 21:44   ` Martin Vidovic
2011-03-12 13:29     ` Andreas Oberritter
2011-03-12 14:05       ` Ralph Metzler
2011-03-12 14:38         ` Andreas Oberritter
2011-03-12 15:06           ` Ralph Metzler
2011-03-12 23:42       ` Oliver Endriss
2011-03-13 10:47         ` Martin Vidovic
2011-03-16 22:07           ` Issa Gorissen
2011-03-18 20:20             ` Martin Vidovic

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=4D7B8A07.70602@linuxtv.org \
    --to=obi@linuxtv.org \
    --cc=flop.m@usa.net \
    --cc=linux-media@vger.kernel.org \
    --cc=rjkm@metzlerbros.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox