← Documents Documentation/userspace-api/media/v4l/rw.rst GitHub 원문 ↗

Linux 6.18.37 · Userspace API / Media / V4L

V4L2 Read/Write I/O

read/write 방식의 지원 조건, 장단점과 드라이버 계약을 설명합니다.

Source pathDocumentation/userspace-api/media/v4l/rw.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

rw.rst:1-47

read/write 방식의 지원 조건, 장단점과 드라이버 계약을 설명합니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 .. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
2 .. c:namespace:: V4L
3
4 .. _rw:
5
6 **********
7 Read/Write
8 **********
9
10 Input and output devices support the :c:func:`read()` and
11 :c:func:`write()` function, respectively, when the
12 ``V4L2_CAP_READWRITE`` flag in the ``capabilities`` field of struct
13 :c:type:`v4l2_capability` returned by the
14 :ref:`VIDIOC_QUERYCAP` ioctl is set.
15
16 Drivers may need the CPU to copy the data, but they may also support DMA
17 to or from user memory, so this I/O method is not necessarily less
18 efficient than other methods merely exchanging buffer pointers. It is
19 considered inferior though because no meta-information like frame
20 counters or timestamps are passed. This information is necessary to
21 recognize frame dropping and to synchronize with other data streams.
22 However this is also the simplest I/O method, requiring little or no
23 setup to exchange data. It permits command line stunts like this (the
24 vidctrl tool is fictitious):
25
26 .. code-block:: none
27
28 $ vidctrl /dev/video --input=0 --format=YUYV --size=352x288
29 $ dd if=/dev/video of=myimage.422 bs=202752 count=1
30
31 To read from the device applications use the :c:func:`read()`
32 function, to write the :c:func:`write()` function. Drivers
33 must implement one I/O method if they exchange data with applications,
34 but it need not be this. [#f1]_ When reading or writing is supported, the
35 driver must also support the :c:func:`select()` and
36 :c:func:`poll()` function. [#f2]_
37
38 .. [#f1]
39 It would be desirable if applications could depend on drivers
40 supporting all I/O interfaces, but as much as the complex memory
41 mapping I/O can be inadequate for some devices we have no reason to
42 require this interface, which is most useful for simple applications
43 capturing still images.
44
45 .. [#f2]
46 At the driver level :c:func:`select()` and :c:func:`poll()` are
47 the same, and :c:func:`select()` is too important to be optional.
48

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

단순한 데이터 교환 방식

1-30

`VIDIOC_QUERYCAP`이 반환한 `v4l2_capability.capabilities`에 `V4L2_CAP_READWRITE`가 설정되어 있으면 입력 장치는 `read()`, 출력 장치는 `write()`를 지원합니다.

드라이버가 CPU로 데이터를 복사할 수도 있지만 사용자 메모리와 DMA를 수행할 수도 있으므로, 이 방법이 버퍼 포인터만 교환하는 방식보다 반드시 비효율적인 것은 아닙니다. 다만 프레임 카운터나 타임스탬프 같은 메타정보를 전달하지 않아 프레임 누락 감지와 다른 스트림과의 동기화에 불리합니다. 반면 설정이 거의 필요 없어 가장 단순합니다.

$ vidctrl /dev/video --input=0 --format=YUYV --size=352x288
$ dd if=/dev/video of=myimage.422 bs=202752 count=1
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
.. c:namespace:: V4L

.. _rw:

**********
Read/Write
**********

Input and output devices support the :c:func:`read()` and
:c:func:`write()` function, respectively, when the
``V4L2_CAP_READWRITE`` flag in the ``capabilities`` field of struct
:c:type:`v4l2_capability` returned by the
:ref:`VIDIOC_QUERYCAP` ioctl is set.

Drivers may need the CPU to copy the data, but they may also support DMA
to or from user memory, so this I/O method is not necessarily less
efficient than other methods merely exchanging buffer pointers. It is
considered inferior though because no meta-information like frame
counters or timestamps are passed. This information is necessary to
recognize frame dropping and to synchronize with other data streams.
However this is also the simplest I/O method, requiring little or no
setup to exchange data. It permits command line stunts like this (the
vidctrl tool is fictitious):

.. code-block:: none

    $ vidctrl /dev/video --input=0 --format=YUYV --size=352x288
    $ dd if=/dev/video of=myimage.422 bs=202752 count=1

드라이버와 애플리케이션의 계약

31-47

애플리케이션은 장치에서 읽을 때 `read()`, 장치에 쓸 때 `write()`를 사용합니다. 데이터를 교환하는 드라이버는 I/O 방법 하나 이상을 구현해야 하지만 반드시 read/write일 필요는 없습니다.

read/write를 지원하는 드라이버는 `select()`와 `poll()`도 지원해야 합니다. 드라이버 수준에서 두 기능은 같으며, `select()`는 선택 기능으로 두기에는 너무 중요합니다.

모든 드라이버에 모든 I/O 인터페이스를 요구할 수 있으면 좋지만, 복잡한 메모리 매핑 I/O가 어떤 장치에는 부적합한 것처럼 정지 영상 캡처 같은 단순 애플리케이션에 유용한 read/write도 모든 장치에 강제할 이유는 없습니다.

To read from the device applications use the :c:func:`read()`
function, to write the :c:func:`write()` function. Drivers
must implement one I/O method if they exchange data with applications,
but it need not be this. [#f1]_ When reading or writing is supported, the
driver must also support the :c:func:`select()` and
:c:func:`poll()` function. [#f2]_

.. [#f1]
   It would be desirable if applications could depend on drivers
   supporting all I/O interfaces, but as much as the complex memory
   mapping I/O can be inadequate for some devices we have no reason to
   require this interface, which is most useful for simple applications
   capturing still images.

.. [#f2]
   At the driver level :c:func:`select()` and :c:func:`poll()` are
   the same, and :c:func:`select()` is too important to be optional.