요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
The High level CI API
=====================
.. note::
This documentation is outdated.
This document describes the high level CI API as in accordance to the
Linux DVB API.
With the High Level CI approach any new card with almost any random
architecture can be implemented with this style, the definitions
inside the switch statement can be easily adapted for any card, thereby
eliminating the need for any additional ioctls.
The disadvantage is that the driver/hardware has to manage the rest. For
the application programmer it would be as simple as sending/receiving an
array to/from the CI ioctls as defined in the Linux DVB API. No changes
have been made in the API to accommodate this feature.
Why the need for another CI interface?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is one of the most commonly asked question. Well a nice question.
Strictly speaking this is not a new interface.
The CI interface is defined in the DVB API in ca.h as:
.. code-block:: c
typedef struct ca_slot_info {
int num; /* slot number */
int type; /* CA interface this slot supports */
#define CA_CI 1 /* CI high level interface */
#define CA_CI_LINK 2 /* CI link layer level interface */
#define CA_CI_PHYS 4 /* CI physical layer level interface */
#define CA_DESCR 8 /* built-in descrambler */
#define CA_SC 128 /* simple smart card interface */
unsigned int flags;
#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */
#define CA_CI_MODULE_READY 2
} ca_slot_info_t;
This CI interface follows the CI high level interface, which is not
implemented by most applications. Hence this area is revisited.
This CI interface is quite different in the case that it tries to
accommodate all other CI based devices, that fall into the other categories.
This means that this CI interface handles the EN50221 style tags in the
Application layer only and no session management is taken care of by the
application. The driver/hardware will take care of all that.
This interface is purely an EN50221 interface exchanging APDU's. This
means that no session management, link layer or a transport layer do
exist in this case in the application to driver communication. It is
as simple as that. The driver/hardware has to take care of that.
With this High Level CI interface, the interface can be defined with the
regular ioctls.
All these ioctls are also valid for the High level CI interface
#define CA_RESET _IO('o', 128)
#define CA_GET_CAP _IOR('o', 129, ca_caps_t)
#define CA_GET_SLOT_INFO _IOR('o', 130, ca_slot_info_t)
#define CA_GET_DESCR_INFO _IOR('o', 131, ca_descr_info_t)
#define CA_GET_MSG _IOR('o', 132, ca_msg_t)
#define CA_SEND_MSG _IOW('o', 133, ca_msg_t)
#define CA_SET_DESCR _IOW('o', 134, ca_descr_t)
On querying the device, the device yields information thus:
.. code-block:: none
CA_GET_SLOT_INFO
----------------------------
Command = [info]
APP: Number=[1]
APP: Type=[1]
APP: flags=[1]
APP: CI High level interface
APP: CA/CI Module Present
CA_GET_CAP
----------------------------
Command = [caps]
APP: Slots=[1]
APP: Type=[1]
APP: Descrambler keys=[16]
APP: Type=[1]
CA_SEND_MSG
----------------------------
Descriptors(Program Level)=[ 09 06 06 04 05 50 ff f1]
Found CA descriptor @ program level
(20) ES type=[2] ES pid=[201] ES length =[0 (0x0)]
(25) ES type=[4] ES pid=[301] ES length =[0 (0x0)]
ca_message length is 25 (0x19) bytes
EN50221 CA MSG=[ 9f 80 32 19 03 01 2d d1 f0 08 01 09 06 06 04 05 50 ff f1 02 e0 c9 00 00 04 e1 2d 00 00]
Not all ioctl's are implemented in the driver from the API, the other
features of the hardware that cannot be implemented by the API are achieved
using the CA_GET_MSG and CA_SEND_MSG ioctls. An EN50221 style wrapper is
used to exchange the data to maintain compatibility with other hardware.
.. code-block:: c
/* a message to/from a CI-CAM */
typedef struct ca_msg {
unsigned int index;
unsigned int type;
unsigned int length;
unsigned char msg[256];
} ca_msg_t;
The flow of data can be described thus,
.. code-block:: none
App (User)
-----
parse
|
|
v
en50221 APDU (package)
--------------------------------------
| | | High Level CI driver
| | |
| v |
| en50221 APDU (unpackage) |
| | |
| | |
| v |
| sanity checks |
| | |
| | |
| v |
| do (H/W dep) |
--------------------------------------
| Hardware
|
v
The High Level CI interface uses the EN50221 DVB standard, following a
standard ensures futureproofness.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
문서 상태와 고수준 접근법
1-24이 문서는 GPL-2.0 라이선스를 따르며 Linux DVB API의 고수준 Common Interface(CI) API를 설명합니다.
주의: 원문은 이 문서가 오래되었다고 명시합니다.
고수준 CI 접근법을 사용하면 거의 임의의 아키텍처를 가진 새 카드도 이 방식으로 구현할 수 있습니다. switch 문의 정의를 카드에 맞게 쉽게 조정할 수 있어 추가 IOCTL이 필요하지 않습니다.
단점은 나머지 처리를 드라이버와 하드웨어가 맡아야 한다는 점입니다. 애플리케이션 개발자는 Linux DVB API가 정의한 CI IOCTL로 배열을 보내고 받기만 하면 되며, 이 기능을 수용하기 위한 API 변경은 없습니다.
단순한 사용자 공간 API를 위해 드라이버와 하드웨어가 프로토콜 처리를 맡습니다.
.. SPDX-License-Identifier: GPL-2.0
The High level CI API
=====================
.. note::
This documentation is outdated.
This document describes the high level CI API as in accordance to the
Linux DVB API.
With the High Level CI approach any new card with almost any random
architecture can be implemented with this style, the definitions
inside the switch statement can be easily adapted for any card, thereby
eliminating the need for any additional ioctls.
The disadvantage is that the driver/hardware has to manage the rest. For
the application programmer it would be as simple as sending/receiving an
array to/from the CI ioctls as defined in the Linux DVB API. No changes
have been made in the API to accommodate this feature.
다른 CI 인터페이스가 필요한 이유
25-49엄밀히 말하면 이것은 새 인터페이스가 아닙니다. DVB API의 `ca.h`는 `ca_slot_info_t`로 CI 인터페이스를 정의합니다.
슬롯 번호, 인터페이스 종류, 상태 플래그를 보관합니다.
`ca_slot_info_t.type`이 나타내는 인터페이스입니다.
모듈 존재와 준비 상태를 구분합니다.
Why the need for another CI interface?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is one of the most commonly asked question. Well a nice question.
Strictly speaking this is not a new interface.
The CI interface is defined in the DVB API in ca.h as:
.. code-block:: c
typedef struct ca_slot_info {
int num; /* slot number */
int type; /* CA interface this slot supports */
#define CA_CI 1 /* CI high level interface */
#define CA_CI_LINK 2 /* CI link layer level interface */
#define CA_CI_PHYS 4 /* CI physical layer level interface */
#define CA_DESCR 8 /* built-in descrambler */
#define CA_SC 128 /* simple smart card interface */
unsigned int flags;
#define CA_CI_MODULE_PRESENT 1 /* module (or card) inserted */
#define CA_CI_MODULE_READY 2
} ca_slot_info_t;
EN50221 APDU 전용 인터페이스
50-77이 CI 인터페이스는 대부분의 애플리케이션이 구현하지 않는 CI 고수준 인터페이스를 따르므로 다시 검토되었습니다. 다른 범주에 속하는 여러 CI 기반 장치를 수용하려 한다는 점에서 일반적인 경우와 다릅니다.
애플리케이션 계층에서 EN50221 형식 태그만 처리하며 애플리케이션은 세션 관리를 맡지 않습니다. 드라이버와 하드웨어가 세션 관리를 처리합니다.
이 인터페이스는 순수한 EN50221 APDU 교환 인터페이스입니다. 애플리케이션과 드라이버 사이에는 세션 관리, 링크 계층, 전송 계층이 존재하지 않으며 이 부분은 드라이버와 하드웨어가 담당합니다.
고수준 CI 인터페이스는 기존 IOCTL로 정의할 수 있고 다음 호출이 모두 유효합니다.
기존 DVB CA 요청 번호와 자료형을 보존합니다.
This CI interface follows the CI high level interface, which is not
implemented by most applications. Hence this area is revisited.
This CI interface is quite different in the case that it tries to
accommodate all other CI based devices, that fall into the other categories.
This means that this CI interface handles the EN50221 style tags in the
Application layer only and no session management is taken care of by the
application. The driver/hardware will take care of all that.
This interface is purely an EN50221 interface exchanging APDU's. This
means that no session management, link layer or a transport layer do
exist in this case in the application to driver communication. It is
as simple as that. The driver/hardware has to take care of that.
With this High Level CI interface, the interface can be defined with the
regular ioctls.
All these ioctls are also valid for the High level CI interface
#define CA_RESET _IO('o', 128)
#define CA_GET_CAP _IOR('o', 129, ca_caps_t)
#define CA_GET_SLOT_INFO _IOR('o', 130, ca_slot_info_t)
#define CA_GET_DESCR_INFO _IOR('o', 131, ca_descr_info_t)
#define CA_GET_MSG _IOR('o', 132, ca_msg_t)
#define CA_SEND_MSG _IOW('o', 133, ca_msg_t)
#define CA_SET_DESCR _IOW('o', 134, ca_descr_t)
장치 질의와 메시지 예
78-109장치에 `CA_GET_SLOT_INFO`를 질의한 예에서는 명령이 `info`이고 슬롯 번호 1, type 1, flags 1을 반환합니다. 애플리케이션은 이를 CI 고수준 인터페이스이면서 CA/CI 모듈이 존재하는 상태로 해석합니다.
`CA_GET_CAP`의 `caps` 예에서는 슬롯 1개, type 1, descrambler key 16개, descrambler type 1을 보고합니다.
`CA_SEND_MSG` 예는 프로그램 수준 CA descriptor `09 06 06 04 05 50 ff f1`을 찾고, ES type 2/PID 201과 ES type 4/PID 301을 포함한 25-byte `EN50221 CA MSG`를 전송합니다.
원문 명령 출력의 핵심 값을 구조화합니다.
On querying the device, the device yields information thus:
.. code-block:: none
CA_GET_SLOT_INFO
----------------------------
Command = [info]
APP: Number=[1]
APP: Type=[1]
APP: flags=[1]
APP: CI High level interface
APP: CA/CI Module Present
CA_GET_CAP
----------------------------
Command = [caps]
APP: Slots=[1]
APP: Type=[1]
APP: Descrambler keys=[16]
APP: Type=[1]
CA_SEND_MSG
----------------------------
Descriptors(Program Level)=[ 09 06 06 04 05 50 ff f1]
Found CA descriptor @ program level
(20) ES type=[2] ES pid=[201] ES length =[0 (0x0)]
(25) ES type=[4] ES pid=[301] ES length =[0 (0x0)]
ca_message length is 25 (0x19) bytes
EN50221 CA MSG=[ 9f 80 32 19 03 01 2d d1 f0 08 01 09 06 06 04 05 50 ff f1 02 e0 c9 00 00 04 e1 2d 00 00]
CA_GET_MSG와 CA_SEND_MSG
110-125API의 모든 IOCTL이 드라이버에 구현되는 것은 아닙니다. API로 직접 구현할 수 없는 하드웨어 기능은 `CA_GET_MSG`와 `CA_SEND_MSG` IOCTL을 사용합니다.
다른 하드웨어와의 호환성을 유지하기 위해 EN50221 형식 wrapper로 데이터를 교환합니다.
CI-CAM으로 보내거나 받는 메시지 구조체입니다.
Not all ioctl's are implemented in the driver from the API, the other
features of the hardware that cannot be implemented by the API are achieved
using the CA_GET_MSG and CA_SEND_MSG ioctls. An EN50221 style wrapper is
used to exchange the data to maintain compatibility with other hardware.
.. code-block:: c
/* a message to/from a CI-CAM */
typedef struct ca_msg {
unsigned int index;
unsigned int type;
unsigned int length;
unsigned char msg[256];
} ca_msg_t;
사용자 공간에서 하드웨어까지의 흐름
126-157사용자 애플리케이션이 데이터를 파싱하고 EN50221 APDU로 포장하면, 고수준 CI 드라이버가 APDU 포장을 풀고 sanity check를 수행한 뒤 하드웨어 의존 동작을 실행합니다.
원문의 ASCII 그림을 같은 처리 순서의 구조화 도식으로 다시 그립니다.
고수준 CI 인터페이스는 EN50221 DVB 표준을 사용합니다. 표준을 따르면 앞으로의 호환성을 확보할 수 있습니다.
The flow of data can be described thus,
.. code-block:: none
App (User)
-----
parse
|
|
v
en50221 APDU (package)
--------------------------------------
| | | High Level CI driver
| | |
| v |
| en50221 APDU (unpackage) |
| | |
| | |
| v |
| sanity checks |
| | |
| | |
| v |
| do (H/W dep) |
--------------------------------------
| Hardware
|
v
The High Level CI interface uses the EN50221 DVB standard, following a
standard ensures futureproofness.
요약·해설
ca_high_level.rst:1-157원문이 오래된 문서라고 경고하는 고수준 CI 설계입니다. 애플리케이션은 EN50221 APDU만 교환하고 세션·링크·전송 계층과 하드웨어 의존 처리는 드라이버와 장치가 맡습니다.