On Monday 19 April 2004 17:07, Johannes Stezenbach wrote:
Hi,
I'm trying to finish my work on the V4 CI API. After a bit of thinking
I made the following changes which I just comitted to CVS:
- one device node for all slots on one CI controller
- define API protocol units to be raw,
On Thu, Apr 22, 2004 at 12:09:56PM +0100, Andrew de Quincey wrote:
On Monday 19 April 2004 17:07, Johannes Stezenbach wrote:
Hi,
I'm trying to finish my work on the V4 CI API. After a bit of thinking
I made the following changes which I just comitted to CVS:
- one device node for all
[...]
* If we supported more than just link level packets, we would have to
extend the read/write interface anyway as we would need a way to specify
the type of packet. However, another way of doing this would be for the
driver to specify what type of packet must be used on a particular
Hi,
I'm trying to finish my work on the V4 CI API. After a bit of thinking
I made the following changes which I just comitted to CVS:
- one device node for all slots on one CI controller
- define API protocol units to be raw, unfragmented TPDUs, i.e.
slightly above link level but not
There's a line
#define MAX_TPDU_SIZE 2048 /* Maximum size of TPDU */
in ci_link_layer.h of the firmware (hope I'm not violating the NDA
too much here... ;-).
Heh. So that is a limit imposed by the firmware/hardware in the av7110. It
won't accept a TPDU packet from the host 2048 bytes.
On Sat, Mar 27, 2004 at 01:18:40PM +, Andrew de Quincey wrote:
On Friday 26 March 2004 15:14, Klaus Schmidinger wrote:
Strange, from what I know a TPDU can be at most 2048 byte long...
Out of interest, where does that 2048 figure come from? I can't see it in
EN50221 or R206-001. I'm
On Thursday 08 April 2004 16:04, Johannes Stezenbach wrote:
On Sat, Mar 27, 2004 at 01:18:40PM +, Andrew de Quincey wrote:
On Friday 26 March 2004 15:14, Klaus Schmidinger wrote:
Strange, from what I know a TPDU can be at most 2048 byte long...
Out of interest, where does that 2048
Johannes Stezenbach wrote:
On Sat, Mar 27, 2004 at 01:18:40PM +, Andrew de Quincey wrote:
On Friday 26 March 2004 15:14, Klaus Schmidinger wrote:
Strange, from what I know a TPDU can be at most 2048 byte long...
Out of interest, where does that 2048 figure come from? I can't see
On Friday 26 March 2004 15:14, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
...
Its just it makes the driver's IO routines _really_ complex, as they have
to deal with multiple connections, multiple slots, the possibility that
the CAM can be yanked out by the user at any time, and
Andrew de Quincey wrote:
I've had to write all this horrendously complicated buffering code in order to
support the CAM link level interface in the kernel; i.e. taking the
multiplexed packet fragments from multiple connection IDs/slots and
reassembling them into full packets. This means the
On Friday 26 March 2004 14:33, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
I've had to write all this horrendously complicated buffering code in
order to support the CAM link level interface in the kernel; i.e. taking
the multiplexed packet fragments from multiple connection IDs/slots
No, please; this is really discouraging, like the diseqc mess;
I wonder why in the kernel there isn't a diseqc implementation, at least
for 1.0 devices and a
simple 2/1 or 4/1 configuration. Currently all players have to implement
it in userspace, and IMHO
this really sucks. Any plan to add
Andrew de Quincey wrote:
...
Its just it makes the driver's IO routines _really_ complex, as they have to
deal with multiple connections, multiple slots, the possibility that the CAM
can be yanked out by the user at any time, and lots of other things. There is
a LOT of complex locking
Andrew de Quincey wrote:
On Friday 26 March 2004 14:33, Klaus Schmidinger wrote:
If it's not hard to do in userspace, why is it so hard in the driver?
Why should every application implement this by itself? I'd say this should
be done by the driver, and the applications shall exchange complete
On Friday 26 March 2004 15:14, Peter Urbanec wrote:
Andrew de Quincey wrote:
On Friday 26 March 2004 14:33, Klaus Schmidinger wrote:
If it's not hard to do in userspace, why is it so hard in the driver?
Why should every application implement this by itself? I'd say this
should be done by the
On Friday 26 March 2004 15:14, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
...
Its just it makes the driver's IO routines _really_ complex, as they have
to deal with multiple connections, multiple slots, the possibility that
the CAM can be yanked out by the user at any time, and
From: Andrew de Quincey [EMAIL PROTECTED]
On Friday 26 March 2004 15:14, Peter Urbanec wrote:
How about adding another layer? Take all this from the driver, but
provide a library implementation that applications can dynamically link
to to get the reassembly for free. That way you get the
On Friday 26 March 2004 15:26, Robert Schlabbach wrote:
From: Andrew de Quincey [EMAIL PROTECTED]
On Friday 26 March 2004 15:14, Peter Urbanec wrote:
How about adding another layer? Take all this from the driver, but
provide a library implementation that applications can dynamically link
There are libraries about which do some of the work, but they all differ in
functionality. Someone needs to pull all the features from each together
into a single mid-level library.
I ended up re-writing everything in user space from scratch for my
company's applications. Unfortunately this
On Fri, Mar 26, 2004 at 03:27:10PM +, Andrew de Quincey wrote:
On Friday 26 March 2004 15:14, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
...
Its just it makes the driver's IO routines _really_ complex, as they have
to deal with multiple connections, multiple slots, the
I'm talking about the layer below that: Each of those TPDU fragments can
be further re-fragmented into multiple link layer packets when they're
actually written to the CAM. Link layer packets can be up to 65535 bytes.
I suppose I could use knowledge of the fact that the higher layers will
On Fri, Mar 26, 2004 at 03:08:18PM +, Andrew de Quincey wrote:
On Friday 26 March 2004 14:33, Klaus Schmidinger wrote:
Andrew de Quincey wrote:
I've had to write all this horrendously complicated buffering code in
order to support the CAM link level interface in the kernel; i.e.
If it were as complicated as you say, userspace would be the right
place. But we have the av7110 firmware implementation, and a proprietary
STB driver, and while it is admittedly not simple there is *no* locking at
all. Because CI is essentially driven by polling (the CAM cannot send
data
Andrew de Quincey wrote:
Its the complex list handling for fragment reassembly thats the bit I don't
see any reason for having cluttering up the kernel. Theres no high bandwidth
data being transferred, so theres no real gain in doing in the kernel.
However, in the av7110 instance, I can
On Friday 26 March 2004 17:53, Johannes Stezenbach wrote:
Andrew de Quincey wrote:
Its the complex list handling for fragment reassembly thats the bit I
don't see any reason for having cluttering up the kernel. Theres no high
bandwidth data being transferred, so theres no real gain in doing
On Friday 26 March 2004 17:53, Johannes Stezenbach wrote:
Andrew de Quincey wrote:
Its the complex list handling for fragment reassembly thats the bit I
don't see any reason for having cluttering up the kernel. Theres no high
bandwidth data being transferred, so theres no real gain in doing
On Friday 26 March 2004 17:53, Johannes Stezenbach wrote:
Andrew de Quincey wrote:
Its the complex list handling for fragment reassembly thats the bit I
don't see any reason for having cluttering up the kernel. Theres no high
bandwidth data being transferred, so theres no real gain in doing
Andrew de Quincey writes:
Sure, thats what I was intending to do. However, I need to finish it first in
line with these new ideas (I've kept the old code though, but that does not
work as I was still debugging it).
I'd like to hear Ralph's or Marcus's opinion, as they originally
On Friday 26 March 2004 18:45, Ralph Metzler wrote:
Andrew de Quincey writes:
Sure, thats what I was intending to do. However, I need to finish it
first in line with these new ideas (I've kept the old code though, but
that does not work as I was still debugging it).
I'd like to
On Friday 26 March 2004 19:18, Johannes Stezenbach wrote:
On Fri, Mar 26, 2004 at 06:17:07PM +, Andrew de Quincey wrote:
However, I have some proposals for fixing the IOCTL interface, to support
different types of CA device properly, and removing some the cruft. I
suggest we then just
On Fri, Mar 26, 2004 at 07:41:17PM +, Andrew de Quincey wrote:
On Friday 26 March 2004 19:18, Johannes Stezenbach wrote:
On Fri, Mar 26, 2004 at 06:17:07PM +, Andrew de Quincey wrote:
However, I have some proposals for fixing the IOCTL interface, to support
different types of CA
31 matches
Mail list logo
