운영체제 기본/Linux의 파일 읽기

관리자 (토론 | 기여)님의 2026년 10월 31일 (토) 06:49 판 (출처·문체 정리: 커널 원문은 git.kernel.org, em dash는 콜론으로 변경)

목차 · 관련 총론: 추상화, 파일과 입출력

응용 프로그램이 read(fd, buf, count)를 호출하면 커널은 fd로 열린 파일 객체를 찾고, 그 객체에 연결된 읽기 구현을 호출한다. 기준은 Linux v6.12다.

소스 링크: Elixir와 Torvalds 저장소의 v6.12 태그.

읽기 전에

파일과 입출력에서 설명한 fd와 open file description의 차이를 알고 있으면 편하다. 여기서는 일반적인 read() 경로를 살펴본다. io_uring, mmap()을 통한 접근 등 모든 입출력 경로를 설명하는 것은 아니다.

fd에서 struct file까지

fd = 3
  |
  +--> current->files     (files_struct)
             |
             +--> fdt     (fdtable)
                    |
                    +--> fd[3] --> struct file

current는 현재 실행 중인 태스크를 나타낸다. current->files로 접근하는 files_struct에 파일 디스크립터 테이블이 연결되어 있고, fdtable.fd는 struct file 포인터의 배열이다. 같은 fd 값도 어느 테이블에서 찾는지에 따라 다른 열린 파일을 가리킬 수 있다.

이 관계를 설명용 의사 코드로 줄이면 다음과 같다. 실제 소스의 연속된 인용이 아니며, 그대로 커널에 넣어 사용할 코드도 아니다.

files = current->files;
table = files->fdt;
opened_file = table->fd[fd];

실제 ksys_read()는 fdget_pos()를 통해 객체를 얻는다. 그 아래의 fdget(), __fget_light()와 조회 함수들은 참조와 동시 접근을 처리한다. 위 그림에서는 이 부분을 생략했다. 직접 배열을 조회하는 코드에는 이러한 보호가 없으므로 실제 조회 함수를 대신할 수 없다.

볼 곳:

struct file에서 읽기 연산까지

struct file의 f_op는 연산 함수들을 모은 file_operations를 가리킨다. 파일마다 응용 프로그램의 호출 형태를 바꾸는 대신, 커널 안에서 해당 대상에 맞는 연산을 선택하는 구조다.

struct file
    |
    +--> f_op (file_operations)
              |
              +--> read
              |
              +--> read_iter

ksys_read()는 얻은 객체를 vfs_read()에 넘긴다. vfs_read()는 접근 모드, 사용자 버퍼 등에 관한 검사를 거쳐 읽기 구현을 선택한다. 분기만 뽑은 설명용 의사 코드는 다음과 같다.

if (opened_file->f_op->read)
    opened_file->f_op->read(...);
else if (opened_file->f_op->read_iter)
    new_sync_read(...);

new_sync_read()는 read_iter 호출에 필요한 요청과 버퍼 정보를 구성한다. 두 함수 포인터를 차례로 모두 호출하는 것이 아니라, 사용할 수 있는 구현에 따라 경로가 갈린다는 점을 확인하면 된다.

볼 곳:

파일시스템으로 넘어가는 경계

응용 프로그램에는 fd와 읽기 인터페이스가 보인다. 커널 내부에서는 테이블 조회로 객체를 찾고, 연산 테이블로 구현을 선택한다.

다만 함수 포인터를 호출하는 것만으로 읽기가 끝나는 것은 아니다. 선택된 구현 아래에서 파일시스템, 캐시, 장치 드라이버 등의 처리가 이어질 수 있다.