Re: [PATCH] Omnikey Cardman 4000 and 5121 support for OpenCT

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Omnikey Cardman 4000 and 5121 support for OpenCT

Harald Welte
On Mon, Apr 18, 2005 at 09:29:51AM +0300, Ville Skyttä wrote:

> On Mon, 2005-04-18 at 07:48 +0200, Harald Welte wrote:
> > On Sun, Apr 17, 2005 at 10:58:45PM +0200, Andreas Jellinghaus wrote:
> >
> > > the header file needs to be mentioned in Makefile.am, so
> > > it will be part of the distribution tar file. since it looks
> > > like an internal header file (seperate from source only for
> > > cleanlyness, not meant to be used by other source files?),
> >
> > it is a header file from the GPL licensed cm4000 kernel driver.
> > I just copied it for convenience.
>
> Note that OpenCT is BSDish licenced.  Luckily, so is the cm4000 driver
> according to the file COPYING in the vendor tarball, and the module
> source has "Dual BSD/GPL".  IANAL, but that looks ok.
header files that just contain #defines and function declarations (no
actual executable code such as inline function) are not copyrighted
works, at least that's what I've learned during all my recent gpl
enforcement efforts.

> > So I could argue that the name 'cardman' for the cm2020 specific driver
> > is actually an overstatement, since it only supports one out of 26
> > cardman products ;)
>
> ...and it doesn't really support even that.
> http://www.opensc.org/openct/ticket/2

oh. Mh.  I don't have that device available, so I can't do debugging.

cm4040 is now basically working, though there are some stability issues
left.  Support requires some changes to ifd-ccid.c, since the cm4040
basically is a CCID device where you pull/push the bulk_in/bulk_out
from/to a FIFO in the IO port range of the PCMCIA card.  Therefore, CCID
code had to be lifted off the assumption that it always has usb beneath
it.

The problem is that the whole idea of a 'pcmcia' device layer doesn't
work, since some pcmcia readers are character based (like serial
readers) and other pcmcia readers are block oriented (like the cm4040).

So sometimes you do want to poll() and wait for more chars to arrive,
but sometimes you don't.  Especially with CCID on top, which always has
a read_len that is bigger than the actually returned RDR_TO_PC response
packet, and incredibly large timeouts.

I've now basically added a "pcmcia_block" layer that doesn't poll and
always only returns the number of bytes read by the first read() call.

--
- Harald Welte <[hidden email]>                  http://gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

signature.asc (196 bytes) Download Attachment