• Module Programming


    - 절차


    - 특징



    - Module 적재 및 제거


    - 기본 구조


    - Module 관련 유틸리티


    - Module Program 작성




  • Device Driver
    : 디바이스와 시스템 사이에 데이터를 주고받기 위한 인터페이스
    : 표준적으로 동일한 서비스 제공을 목적
    : 커널의 일부분으로 내장
    : 서브루틴과 데이터의 집합체
    : 디바이스의 고유한 특성을 내포




    - Device 종류



    - 디바이스 파일



    - File Operations







    ■ Character Device Driver


    ■ Ext4_file_operations



    - 디바이스 드라이버 구현



    : 모드간 데이터 전송

     

     

     : I/O 영역 경쟁 처리

     

     

     

    : 디바이스 종류별 등록/해제

     


    문자 디바이스 드라이버
     - 2.6 이후
      1. 디바이스 번호 등록
      2. cdev 구조체 생성 및 초기화
      3. 디바이스 등록 cdev_add(); -> module_init();
      4. file_operations 구조체에 대입될 함수들을 작성

    - 출처 : http://blog.dasomoli.org/223

    : register_chrdrv_region 함수는 원하는 디바이스의 번호를 미리 알고 있을 때 사용하고, alloc_chrdev_region 함수는 디바이스의 번호를 동적으로 할당받아 파라미터로 받는 dev_t 구조체 포인터를 이용해 dev_t 구조체에 넣는다.
    register_chrdrv 대신 register_chrdrv_region을 사용하는 것으로 혼동할 수 있는데 그게 아닌 cdev_add 함수까지 사용하여야 한다. 실제 커널 소스의 register_chrdrv 함수를 보면 이런 과정이 구현되어 있음을 볼 수 있다.
    cdev_add 함수를 사용하기 위해서는 struct cdev 구조체를 사용하여야 하는데 이 구조체를 초기화 시켜주는 함수가 cdev_init 이다. struct cdev 구조체 등을 사용하려면 <linux/cdev.h> 를 include하여야 한다. 다음은 사용 예이다.

     
    #include <linux/kernel.h>
    #include <linux/cdev.h>
    #include <linux/fs.h>
    
    ...
    struct file_operations dasom_fops;
    
    static struct cdev dasom_cdev = {
        .owner = THIS_MODULE,
        .ops = &dasom_fops,
    };
    
    int _init dasom_init(void)
    {
        dev_t dev;
        int err = 0;
    
        if(major) {
            dev = MKDEV(major, minor);
            err = register_chrdev_region(dev, 1, "dasomoli");
        } else {
            err = alloc_chrdev_region(&dev, mior, 1, "dasomoli");
            major = MAJOR(dev);  
        }
        if(err < 0) {
            err = -ENODEV;
            return err;
        }
        ...
        
        cdev_init(&dasom_cdev, &dasom_fops);
        dasom_cdev.owner = THIS_MODULE;
        dasom_cdev.ops  = &dasom_fops;
    
        if(cdev_add(&dasom_cdev, dev, 1)) {
            printk(KERN_INFO"dasom: cdev creation failed.\n");
            err = -ENODEV;
            goto error_label;
        }
        
        ...
        
        return 0;
        
    error_label:
        return err;
    }
    


     - 2.6 이전
     
     

     블록 디바이스 드라이버
     
     

    ■ 

    네트워크 디바이스 드라이버

     
     

    - Character Device Driver with VFS


    - File System and Device Driver




  • 전체 요약







'Major > Linux' 카테고리의 다른 글

리눅스 - 디바이스 드라이버  (2) 2016.02.15
리눅스 - Ext4 File System  (0) 2016.02.01
리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (6) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
  1. ysj 2019.01.22 17:55

    오우 베리굿

  2. OSOR2 2021.02.10 10:03 신고

    정말 좋은 자료입니다. 감사합니다

  • Ext4 File System
    : Extended File System
    : Ext2, Ex3 에 이은 리눅스의 최신 파일 시스템

    -> Ex2, Ex3에 비해 최대 지원 파일 크기, 디스크 할당 정책, 저널링, 단편화 해소 등 많은 부분 성능이 향상된 파일 시스템

    - 특징
     ■ 더 큰 파일 시스템과 파일 사이즈
      : 현재 Ext3는 최대 16Tib의 파일시스템 사이즈와 최대 2Tib의 파일 사이즈를 지원
      : Ext4는 48 비트 블록 주소 (48-bit block addressing)를 추가했고, 1EB(2^60)의 최대 파일 시스템 사이즈와 16Tib의 최대 파일 사이즈를 가짐
      -> 4KB x 2^48 = 1EB
      ∴ 왜 64비트가 아니고 48비트?
      : Ext4에 어드레스될 완벽하게 안정적인 48비트가 있기 전에 Ext4가 만들어졌기 때문에 어드레스 비트를 48로 제한할 필요가 있었음.

     ■ 서브 디렉토리 확장성
      : 서브 디렉토리들의 가능한 최대 수는 Ex3에 있는 싱글 디렉토리를 포함하여 32000인데 Ext4는 두배의 값까지 가질 수 있게 되어서 64000의 서브 디렉토리를 허용

     ■ 입출력 성능 향상

      : 익스텐트 (Extent)
      : 다중 블록 할당 (Multiblock allocation)
      : 지연 할당 (Delayed allocation)
     
     ■ 그 외 특징들
      : 저널링 체크섬 - Ext4 체크섬은 블록에 결함이나 붕괴가 있다면 그것을 알 수 있도록 해줌
      : Lager inodes - Ext3은 아이노드 크기를 변경하는 것을 지원 그러나 기본적인 아이노드 크기는 128바이트 -> Ext4는 기본적인 아이노드 크기를 256 바이트로 함
      : Inode reservation - 디렉토리가 만들어질 때 미래에 사용될 몇몇의 아이노드들을 예약하는 것으로 구성



  • Ext4 Partition
    - 파일 시스템 블록 구성
     : 블록 크기 - 1KB ~ 4KB (default 4KB)
     : 파일시스템을 구성하는 정보들은 각 block group에 분산
     : 파일을 저장할 때 특정 부분에 집중적으로 기록하여 하드디스크의 효율을 높이고자 함 (파일 단편화를 줄임)
     : Block group 당 최대 블록의 개수 (블록이 4KB로 가정)
      -> 4KB = 8(bits) x 4096 = 32,768 bits
      -> 32KB X 4KB = 128MB (block group의 최대 크기)
      -> 1024MB / 128MB = 80개 (1GB 일 때 80개의 그룹 생성)

     


      ■ Super Block

       : Super Block이 손상되면 전체 파일 시스템에 대한 정보를 잃기 때문에 Super block과 group descriptor table의 사본은 모든 block group에 저장
       : 각 block group의 첫 번째 block에 위치
       : 해당 파일 시스템 관련 정보 저장 [블록의 크기(1KB, 2KB, 4KB), 총 블록의 개수, 블록 그룹의 개수, Inode의 개수, 그룹 내의 블록/Inode의 개수]
       : $dumpe2fs /dev/sdb1

      ■ Group Descriptor Table
       : Super block 바로 다음 block에 위치
       : 각 Block Group을 관리하는 정보 저장[Block Bitmap의 블록 번호, inode Bitmap의 블록 번호, 첫 번째 inode Table Block의 블록 번호, 그룹 안에 있는 빈 블록 수, 그룹 안에 있는 inode 수, 그룹 안에 있는 빈 디렉토리 수)

      ■ Block bitmap
       : 이 블록에 속한 각 비트는 그룹 내에 있는 각 블록의 사용 상태를 나타냄
       : Block 크기가 4KByte면 4K*8개 블록의 사용 여부 표시
       

      ■ inode
       : inode (index node)
        - 파일에 대한 제어 정보 및 데이터 블록 포인터 저장
        - 모든 파일들과 디렉터리들은 각각 1개의 inode를 할당
       : inode bitmap
        이 블록에 속한 각 비트는 그룹 내에 있는 각 inode의 사용 상태를 나타냄
       : inode table
        - 각각의 i
    node에 대한 정보를 나타내는 inode descriptor로 구성
        - inode table은 Group Descriptor Table에 저장
        - inode 번호를 알면 inode가 속한 Group을 알 수 있음
         -> Block group = (inode - 1) / INODES_PER_GROUP
        
       : inode descriptor
        - Mode, Owner Info, Size, Timestamp
        - Blocks pointers array (파일의 실제 데이터가 저장된 위치)
        

    - 디렉토리 구조


    Blocks vs Pages
     : block는 OS에서 파일을 읽거나 쓰는 가장 작은 데이터의 단위
     : page는 몇몇 OS에서 block 대신 사용된다. page는 기본적으로 virtual block 이며, 4K나 2K로 고정된 크기를 가진다.
     => page는 고정된 크기를 가진 virtual block 
     : 왜 blocks 대신에 pages를 사용할까? - page는 다양한 storage 장치에서 프로세싱을 더 쉽게 만든다. 각각의 디바이스들은 서로 다른 크기의 블록크기를 지원한다. page는 이것을 OS 시스템에서 같은 크기의 page 사이즈로 다룰 수있도록 한다. 이것은 크기가 다른 모든 블록 사이즈들을 계산하고 다루는것 보다 효율적이다. 그래서 페이지는 하드웨어 드라이버와 OS 시스템의 sort of a middleman 역할을 한다.
     =
    > 페이지들이 적절한 블록으로 해석된다.
     : page, blocks 모두 data storage의 기본단위로 사용된다.

  • Ext4 Performance vs Ext3
     

  • Ext2,3 vs Ext4 메커니즘
    - 블록 매핑
     ■ Extent
      - 이전 파일 시스템의 단점
       : Ext3과 같은 유닉스 드라이버의 파일 시스템은 각각의 블록(파일의 데이터에 해당하여 사용되는)들의 트랙을 유지하기 위해 간접 블록 매핑 스키마를 사용
       -> 이것은 큰 파일에 대해서 비효율적이며 특히 큰 파일을 삭제하거나 절단 명령 동안에 비효율적. 왜냐하면 모든 싱글 블록 엔트리에 대한 매핑은 그것이 큰 파일(많은 블록들을 가지고 있는)에 해당할때 거대한 매핑을 필요로 하며 핸들이 느려짐

      - 연속 할당의 변형된 기법
      : 어느 정도의 연속된 공간만 초기에 할당
      : 그 양이 충분히 크지 않을 때. 추후 또 다른 연속된 공간을 익스텐트(extent)라고 부르는 단위로 할당
      : 파일 블록들의 위치는 위치와 블록 수, 다음 익스텐트의 첫 블록을 가리키는 포인터로 기록
      : Ext2,3 Indirect Block vs Ext4 Extent
           

         

     ■ 다중 블록 할당 (Multiblock Allocation)
       - 이전 파일 시스템의 단점
       : 새로운 데이터를 디스크로 쓸 필요가 생길 때, 블록 할당자(Block Allocator)는 데이터가 쓰여질 가용 공간을 결정
       : Ext2,3 블록 할당자는 오직 한번에 한 개의 블록(4KB)만 할당 할 수 있음
       - 만약 시스템이 100MB의 가용공간이 필요하다면 Ext2/3 블록 할당자는 25600번 (100MB = 25600 블록)의 블록 할당 호출을 하게 됨 -> 단일 블록만을 다루기 때문

       - Ext4의 다중 블록 할당
       : Ext4는 매 호출마다 싱글 블럭을 할당하는 대신에 많은 오버헤드를 피하기 위해서 한번의 호출로 많은 블록을 할당할 수 있는 다중 블록 할당자(multi block allocator)를 사용 

     ■ 지연 할당 (Delayed Allocation)
      - 이전 파일 시스템의 할당 정책
      : write() 연산의 경우, 파일 시스템 코드는 심지어 데이터가 디스크에 즉시 쓰여지고 있지 않더라도 이것을 일정한 시간동안 캐시에 유지한 채 즉시 데이터가 위치할 블록으로 할당
      : 이러한 접근은 단점 가짐. 가령 커지는 파일에 지속적으로 write() 연산을 할 때 데이터의 블록으로의 성공적인 write() 할당이 이루어지더라도 그 파일이 계속 커질 것이라는 것은 알지 못하기 때문

      - Ex4의 지연 할당
      : 파일이 캐시에 유지되어 있는 동안에는 그 파일이 실제로 디스크에 쓰여질 때 까지 블록으로의 할당을 지연시킴

     => 시너지 (Synergy)
      : Ext4의 Extent, Multi Allocation, Delayed Allocation은 서로의 특성과 함께 효율적으로 디스크 할당을 수행함
      1. 파일이 디스크에 쓰기를 마쳤을 때 생기는 많은 작업량은 extents로 인접한 블록으로의 할당이 준비
      2. multi block allocation에 의해 많은 작업량에 대한 큰 블록이 할당될 수 있음
      3. 지연된 할당은 위의 두 특성이 효율적으로 작동할 수 있도록 해줌

    - 저널링 [Journaling (Ext3.4)]
     : 시스템이 멈추거나 정전 등으로 꺼지는 경우
      -> 일관성 문제 발생
     : 부팅 시
      - e2fsck (fsck.ext2)를 이용한 일관성 검사
      - 파일 시스템을 마운트하는 시점에 검사 수행
      - 저장장치 내의 모든 inode와 비트맵 검사

     : 모든 저널 로그들은 트랜잭션 단위로 그룹화
     : 각각의 트랜잭션들은 시퀀스 번호를 부여받음
     : 저널 데이터
      - 각 트랜잭션을 관리할 수 있는 정보와 파일 시스템의 변경 내역에 대한 데이터를 가지고 있음
     : e2fsck
      - Commit 된 저널 데이터의 경우 정상 분류하여 해당 데이터들을 파일시스템에 기록
      - Commit 되지 않은 저널의 경우 완료되지 않은 데이터이므로 무시하고 넘어감

     ■ Journaling File System

       : 데이터베이스의 기본적인 특징들을 구현
        - Logging을 이용한 데이터 백업 체계
       : Journal 영역
        - 로그를 기록
        - Commit: 작업이 정상적으로 종료될 경우
        - Rollback: 비정상 종료일 경우 원래의 상태로 복구



  • read(), write() 시스템 콜 루틴


    - read() system call in file system
     

    - read() system call trace (출처 : 수원 삼성소프트웨어멤버십 송인주)
    ∴ 가정
     : 파라미터로 파일 디스크립터, 버퍼, size를 가지는 가장 일반적인 read() 시스템 콜
     : 장치 파일을 통한 읽기가 아닌 파일 시스템을 사용하는 데이터 읽기
     : 읽고자 하는 파일은 이미 open() 되었음
     : O_DIRECT 플래그를 주지 않았기 때문에 페이지 캐시에 접근
     : 페이지 캐시에 read 하고자 하는 페이지가 없음 -> 블록 I/O 요청을 발생시킴
     : 디스크 파일 시스템은 Ext4
     : 디스크는 SCSI Disk Device를 사용
     -> 그러므로 블록 I/O 처리 시 로드되는 디바이스 드라이버는 SCSI 디바이스 드라이버







    - write() system call trace


'Major > Linux' 카테고리의 다른 글

리눅스 - 디바이스 드라이버  (2) 2016.02.15
리눅스 - Ext4 File System  (0) 2016.02.01
리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (6) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
  • VFS(Virtual File System)



  • VFS의 역할 및 구조


    - VFS가 지원하는 파일 시스템
      디스크 기반 파일 시스템
      : 로컬 디스크 파티션의 기억 장소 또는 디스크를 흉내내는 몇 가지 다른 장치(USB 플래시 드라이브 같은)를 관리
      : Ext2, Ext3, Ext4, MS-DOS, FAT, NTFS, SYSV 등
      네트워크 파일 시스템
      : 네트워크로 연결된 다른 컴퓨터의 파일 시스템을 쉽게 접근가능하게 함
      : NFS(Network File System), AFS(앤드류 파일 시슽엠) 등
       
     ■ 특수 파일 시스템
      : /proc 파일 시스템, /tmp 파일 시스템 등
      

  • VFS 메커니즘
    - 공통 파일 모델 (Common File Model)

     : VFS의 핵심 개념은 지원하는 모든 파일 시스템을 표현할 수 있는 공통 파일 모델을 도입 하는 것
     : 각각의 특정 파일 시스템을 구현 하려면 반드시 자신의 물리적인 구성을 VFS의 공통 모델로 변환해야 함
     -> 예를 들어 몇몇 비 유닉스 계열의 디스크 기반 파일 시스템은 각 파일의 위치를 저장한 파일 할당 테이블(FAT)를 사용 -> 이런 파일 시스템에서 디렉토리는 파일이 아님
     -> VFS의 공통 파일 모델을 따르도록 하기 위해 실행 중에 디렉토리에 대응 하는 파일을 생성, 이렇게 생성한 파일을 커널 메모리 객체에 만듦
     => 공통 파일 모델을 구현하기 위한 자료구조(object)
       : 슈퍼 블록 객체, 아이노드 객체, 파일 객체, 디엔트리 객체

    - 프로세스와 VFS 객체의 상호작용
     

    - 공통 파일 모델 객체
     ■ 슈퍼 블록 객체
      : 마운트 된 파일 시스템에 대한 정보를 저장, 전체 파일 시스템을 나타냄
     ■ 아이노드 객체
      : 특정 파일에 대한 일반 정보를 저장. 디스크에 저장한 파일 제어 블록 (FCB, 리눅스에서는 아이노드)에 대응, 각 아이노드 객체에는 아이노드 번호가 할당)
     ■ 파일 객체
      : 열린 파일과 프로세스 사이의 상호 작용과 관련한 정보를 저장. 각 프로세스가 열린 파일을 가지는 동안 커널 메모리에만 존재
     ■ 디엔트리 객체
      : 디렉토리 항목(특정 파일 이름과 아이노드)과 이에 대응하는 파일의 연결에 대한 정보를 저장.

    - VFS 디엔트리 캐시

     : 가장 최근에 사용한 디엔트리 객체를 저장하는 디스크 캐시

     ∴ 디스크 캐시?
      : 보통 디스크에 저장하는 정보 중 일부를 램에 저장하여 이후 정보에 접근할때 더 느린 디스크에 접근하지 않고 빨리 처리하도록 하는 소프트웨어 메커니즘
      : 이렇게 함으로써 파일 경로명을 공려명의 마지막 구성요소인 파일 아이노드로 변환하는 속도를 높임

     ∴ 리눅스의 디스크캐시

      : 디엔트리 캐시, 아이노드 캐시, 페이지 캐시

    - VFS의 시스템 콜 처리 루틴
     

     : 애플리케이션이 read() 시스템 콜 호출 -> 커널은 해당하는 sys read() 호출
     : 커널 메모리 안에 있는 파일 객체의 f op 필드에 타겟 파일 시스템의 해당 함수 처리 루틴이 포인터로 존재
     : read() -> sys_read() -> vfs_read() -> (file->f_op) -> MS-DOS read()

      ■ open() 시스템 콜 메커니즘

       : open() 시스템 콜 -> sys_open() 시스템 콜이 성공하면 파일 객체에 대한 포인터 배열인 current->files->fd 의 인덱스를 반환
       : sys_open() 함수의 동작
       ① fd 반환

       ② 파일 객체의 주소 반환

       ③ f_op 필드를 대응하는 아이노드 객체의 i_fop 필드 내용으로 설정 -> 파일 연산을 위한 메소드 설정 종료

       ④ 탐색된 디엔트리 객체와 마운트된 파일 시스템 객체 등으로 파일 객체 할당

       ⑤ 접근 모드 플래그를 매개변수로 경로명 탐색 시작

       ⑥ 빈 파일 디스크립터 번호를 지역 변수에 저장

       ⑦ 프로세스 주소 공간에서 파일 경로명을 읽음

     

    - VFS가 처리하는 시스템 콜
     



'Major > Linux' 카테고리의 다른 글

리눅스 - 디바이스 드라이버  (2) 2016.02.15
리눅스 - Ext4 File System  (0) 2016.02.01
리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (6) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28

File Descriptor (파일 디스크립터) [출처: http://dev.plusblog.co.kr/22]


1. 파일 디스크립터

- 시스템으로부터 할당 받은 파일을 대표하는 0이 아닌 정수 값

- 프로세스에서 열린 파일의 목록을 관리하는 테이블의 인덱스



흔히 유닉스 시스템에서 모든 것은 파일이라고 한다. 일반적인 정규파일(Regular File)에서부터 디렉토리(Directory), 소켓(Socket), 파이프(PIPE), 블록 디바이스, 캐릭터 디바이스 등등 모든 객체들은 파일로써 관리된다. 유닉스 시스템에서 프로세스가 이 파일들을 접근할 때에 파일 디스크립터(File Descriptor)라는 개념을 이용한다.


파일 디스크립터는 '0이 아닌 정수', 'Non-negative Integer' 값이다. 즉, 음수가 아닌 0과 양수인 정수 값을 갖는다. (unsigned int 값이라고 보면 된다.) 프로세스가 실행 중에 파일을 Open 하면 커널은 해당 프로세스의 파일 디스크립터 숫자 중에 사용하지 않는 가장 작은 값을 할당해 준다. 그 다음 프로세스가 열려있는 파일에 시스템 콜을 이용해서 접근 할 때, FD 값을 이용해 파일을 지칭 할 수 있다. 


프로그램이 프로세스로 메모리에서 실행을 시작 할 때, 기본적으로 할당되는 파일 디스크립터들이 있다. 바로 표준 입력(Standard Input), 표준 출력(Standard Output), 표준 에러(Standard Error)이다. 이 들에게 각각 0, 1, 2 라는 정수가 할당되며, POSIX 표준에서는 STDIN_FILENO, STDOUT_FILENO, STDERR_FILENO로 참조된다. 이 매크로는 <unistd.h> 헤더 파일에서 찾아 볼 수 있다. 

0이 아닌 정수로 표현되는 파일 디스크립터는 0 ~ OPEN_MAX 까지의 값을 가질 수 있으며, OPEN_MAX 값은 플랫폼에 따라 다르다.






파일 디스크립터는 위 그림을 보면서 개념 정리를 하면 좋다. 파일 디스크립터가 단순히 숫자인 이유는 프로세스가 유지하고 있는 FD 테이블의 인덱스이기 때문이다. FD 3번이라는 의미는 FD 테이블의 3번 항목이 가리키는 파일이라는 의미이다. FD 테이블의 각 항목은 FD 플래그와 파일 테이블로의 포인터를 가지고 있다. 이 포인터를 이용하여 FD 를 통해 시스템의 파일을 참조 할 수 있는 것이다.

프로세스는 이런 FD 테이블과 파일 테이블의 정보를 직접 고칠 수 없으며, 반드시 커널을 통해서 수정을 해야 한다.

파일 디스크립터란 뭔가?! [출처: http://z-man.tistory.com/151]

파일 디스크립터는 파이프, FIFO, 소켓, 터미널, 디바이스, 일반파일 등 종류에 상관없이 모든 열려있는 파일을 참조할때 쓴다.

파일디스크립터 

목적 

POSIX 이름 

stdio 스트림 

 0

 표준 입력

 STDIN_FILENO

 stdin

 1

 표준 출력

 STDOUT_FILENO

 stdout

 2

 표준 에러

 STDERR_FILENO

 stderr

 

표에 있는 3가지 디스크립터는 프로그램이 시작할때 셸의 디스크립터의 복사본을 상속 받고, 셸은 보통 3가지 파일 디스크립터가 언제나 열린채로 동작 한다.

프로그램에서 파일 디스크립터를 참조할때는 번호(0,1,2)를 쓸 수도 있지만 가능하면 "UNISTD.H"에 정의된 POSIX 이름을 쓰는편이 좋다..

 

1
2
3
4
5
6
7
8
fd = open( pathname, flags, mode )
// pathname 이 가리키는 파일을 열고 열린 파일을 이후 호출에서 참조 할 때 쓸 파일 디스크립터를 리턴.
// flags는 파일을 읽기, 쓰기, 둘다를 위해 열지를 지정 한다.
numread = read( fd, buffer, count )
// fd가 가리키는 파일에서 최대 count 바이트를 읽어 buffer에 저장.
numwritten = write( fd, buffer, count )
// 버퍼에서 최대 count 바이트를 fd가 가리키는 열려 있는 파일에 쓴다.
status = close(fd) 모든 i/o 를 마친뒤 fd와 관련 커널 자원을 해제 한다.

fd는 해당 프로세스의 open file 을 관리하는 구조체 배열의 index.

그 구조체의 index 가 가리키는 객체가 dentry 라는 객체이고, 그 dentry 객체는 또다시 해당 파일을 나타내는 inode 객체를 가리키게 됩니다.

커널 구조체중 struct files_struct 보시면 struct file fd_array 라는 배열이 있다.
실제로 open()을 통해 얻는 fd 는 저 구조체의 index 를 나타냅니다.

일반적으로 0, 1, 2 index 는 std-in/std-out/error 와 관련된 fd 로 미리 할당이되고, 보통 open()을 하게 되면 fd 값은 3이 됩니다.

3 번 index 로 test.txt 를 찾는 방법은 
우선 fd_array[3] 이 pointing 하고 있는 file 구조체의 f_dentry 를 얻어오게됩니다. dentry 란 것은 directory entry 를 의미하는데, 리눅스에서 디렉토리에 접근을 빠르게 하기 위한 구조체로 사용하고 있습니다. open() 시스템 콜을 호출하게 되면, test.txt 가 존재하는 위치와 관련되어 dentry 구조체가 만들어집니다.

dentry 구조체는 관련된 inode 구조체를 가리키는 필드를 포함합니다.
따라서 open("test.txt',...) 함수로 호출된 파일은 test.txt 에 대한 dentry 생성, inode 생성(또는 읽음) 후에 해당 프로세스의 open 파일 관리 구조체인 files_struct 의 fd_array 의 비어있는 위치에 test.txt 의 dentry 를 포인팅하고 그 index 인 3을 넘겨주는 것입니다.

이후 사용자가 3번을 가지고 시스템 콜을 수행하게되면, 해당 프로세스의 files_struct 의 fd_array index 를 통해서 관련 inode에 접근할 수 있게 되는 것입니다.

 

파일 디스크립터와 열려 있는 파일의 관계

각 프로세스별로 커널은 open file descriptor table 을 갖고 있다. 테이블의 각 엔트리는 하나의 파일 디스크립터에 대한 동작 제어 플래그, 열린 파일을 가리키는 참조를 담고 있다.

open file description은 현재 파일의 offset, flag, 접근 모드, i/o 관련 설정, 파일의 i-node 객체를 가리키는 레퍼런스를 갖고 있다.

i-node는 파일 종류 (일반파일, 소켓, fifo)와 권한, lock 목록 포인터, 여러 파일 오퍼레이션과 다양한 파일 속성(크기, 타임스탬프등)을 갖고 있다.

만약 같은 open file description을 가리키는 2개의 fd는 offset값을 공유 한다.

'Major > Linux' 카테고리의 다른 글

리눅스 - Ext4 File System  (0) 2016.02.01
리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (6) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
리눅스 - 기초  (0) 2016.01.28
  1. fundamental 2018.02.19 13:23

    좋은 설명 감사합니다 잘읽고갑니다

  2. M_Falcon 2019.06.16 00:31 신고

    파일 디스크립터에 관한 가장 이해가 잘되는 글이였습니다. 감사합니다.
    퍼갈게요!

  3. 알파카 2019.12.09 19:23

    잘 배워갑니다. 안 선생님.

  4. 이글루 2020.12.19 11:38

    친절한 설명 감사합니다.

  5. 얍얍 2020.12.22 14:06

    잘읽었습니다.
    글초반부 음이 아닌 정수가 아닌 0이 아닌 정수로 잘못 번역된것 같습니다.

  6. 도젼 2021.01.25 18:31 신고

    너무 좋은 설명이에요!! 덕분에 쉽게 이해했네요 좋은 글 감사합니다:)

  • 파일 시스템 (File System)
    : 저장장치 내에서 데이터를 읽고 쓰기 위해 미리 정해진 약속
    : 파일 저장 및 검색을 용이하도록 유지/관리하는 방법
    : 파일을 어떻게 관리할 것인가에 대한 메커니즘과 정책
    : 파일 + 디렉토리 구조
    : EXT2, EXT3, FAT, FAT32, NTFS, JFFS, JFFS, JFFS2, ISO 9660 ...
    : Journaling File System - 파일 시스템의 변화를 기록해 두었다가 시스템 결함으로 문제가 발생할 경우 파일 시스템 복구

       

    - 섹터에 대한 파일 매핑
     

    - 기능
     : 파일 생성, 제거, 수정
     : 타인과 파일 공동 사용
     : Backup & Recovery
     : 물리적 장치 이름 대신 기호화된 이름 사용- 장치와의 독립성 제공 : C:, D:, /, /home, /dev/sda1
     : 정보의 안전한 보관편리한 인터페이스
     : 타겟 저장장치에 따른 최적화된 접근, 할당 정책
     
  • 파일 (File)
    : 디스크와 같은 물리적인 저장 매체에 저장되는 데이터 집합
    : 데이터 정보에 대한 논리적인 저장 단위
    : 저장장치의 물리적 특성을 추상화한 논리적 저장 단위
    : 자료가 파일 안에 존재해야만 보조 저장장치에 기록될 수 있음

    - 속성(Attributes)

     : 이름, 식별자, 타입, 위치, 크기, 보호, 시간 등
     : 파일의 내용을 제외한 파일의 모든 정보는 보조 저장장치에 상주하는 디렉터리 구조 내에 유지
     : 1단계, 2단계 디렉터리 구조, 트리 구조 디렉터리, 일반 그래프 디렉터리 구조 등 다양한 디렉터리 구조가 존재
     

  • 할당 방법 (Allocation Methods)
    : 파일 시스템은 파일을 디스크 블록(block)이라는 논리적인 단위의 집합으로 관리
     -> 사용자가 파일을 디스크에 저장하기를 요청하면 파일은 블록단위로 분할되어 파일 시스템 정책에 따라 일정한 장소에 내용을 기록
     -> 블록의 크기는 1KB, 4KB, 16KB, 64KB 등
    : 디스크 할당의 주요 문제는 파일들을 어떻게 디스크 공간에 배치해야 디스크 공간을 효율적으로 사용할 수 있고, 파일들에 빨리 접근할 수 있는가
    : 디스크의 직접 접근 특성이 파일의 구현에 융통성을 허용

    - 디스크 블록 할당 방법
     ■ 연속 할당 (Contiguous Allocation)
      : 하나의 파일을 디스크 내의 연속된 블록에 순차적으로 할당하는 방법, 디스크 탐색 횟수를 최소화
      : 가용 공간을 선택하는 방법 - First-Fit, Best-Fit, Worst-Fit
      : 파일의 크기가 가변적으로 변화되는 경우 연속 할당을 사용할 경우 성능 저하 발생
      : 내부 단편화, 외부 단편화 발생
       

     ■ 불연속 할당 (Disc
    ontiguous Allocation)
      : 불연속적인 공간에 흩어진 디스크 블록에 나누어 저장

      □ 연결 할당(Linked Allocation)
       : 흩어진 블록들을 연결 리스트로 관리
       : 순차 접근인 경우 효과적이지만 직접 접근 시에는 매우 비효율적 -> 포인터 접근 시마다 디스크 읽기와 탐색 오버헤드 존재
       : FAT
       : 연속 할당의 문제점인 외부 단편화와 내부 단편화 문제를 해결

       

      □
     색인 할당(Indexed Allocation)
       : 디스크 블록에 대한 위치 정보를 가지고 있는 인덱스 블록 사용
        -> 블록이 할당될 때마다 해당 정보를 인덱스 블록에 기록
        -> 직접 접근 문제 해결. 인덱스 블록 유지 비용 발생
       : 파일이 커지면 하나의 인덱스 블록만으로 관리 불가능
        -> 여러 개의 인덱스 블록이 필요하면 이를 연결리스트로 관리
       : Linux는 inode 기법을 이용
       

  • 리눅스 파일 시스템 계층 분석

     

    - 리눅스 디스크 접근
      장치 파일은 /dev에 위치

      : 디스크가 설치되면 장치 파일을 이용하여 해당 디스크 접근

      -> /dev/sdb3 -> SCSI 타입의 두 번째 디스크의 세 번째 파티션

      -> /dev/sda1 -> SCSI 타입의 첫 번째 디스크의 첫 번째 파티션

     ■ 파티션 (partition)
      : 물리 장치의 논리적인 분리
      : 파일 시스템은 파티션마다 하나씩 만들어짐

      -> SCSI 타입의 하드 디스크 -> sda, sdb

      -> IDE 타입의 하드 디스크 -> hda, hdb


    - Mount
     : 파일 시스템을 트리 구조의 특정 노드에 mapping하는 역할
     : Root file system -> 시스템 부팅 시 root directory로 mount 됨
     : 각각의 파일 시스템은 마운트될 위치를 지정해 mount 명령으로 마운트시키거나 unmount 명령으로 언마운트(해체)할 수 있음
     ■ mount 과정
      ① 추가된 HDD가 정상적으로 인식되었는지 확인

       -> cat /var/log/dmesg | grep sdb
      ② 파티션 생성
       -> fdisk /dev/sdb
      ③ 파일 시스템 생성
       -> mkfs -t ext3 /dev/sdb1
      ④ 파일 시스템 마운트
       -> mkidr /home2  (Mount point 생성)
       -> mount -t ext3 /dev/sdb1 /home2 (새로 추가한 HDD를 /home2로 마운트)

    - 계층 개요
     


      ■ 가상 파일 시스템 (VFS : Virtual File System)
       : 표준 유닉스 파일 시스템이 제공하는 모든 시스템 콜을 처리하는 커널 소프트웨어 계층
       : 여러 종류의 파일 시스템에 대해 공통 인터페이스를 제공함


      ■ 디스크 파일 시스템 (Ext2,Ext3,Ext4 등)
       : 디스크나 입출력 장치에 정보를 저장하거나 입출력 및 검색 등을 하기 위한 계층

       : 장치에의 입출력이나 저장 형태 등, 장치에 의존적인 부분은 감추고 사용자에게 논리적이고 장치에 독립적인 쉬운 사용 인터페이스를 제공하기 위해 존재.


      ■ 페이지 캐시 (=Disk Cache)
       : 디스크의 정상적인 일부 데이터를 램이 보유하는 소프트웨어 메커니즘.
       : 
    Page라는 단위로 메모리에 일부 데이터를 저장.
       -> 한번 접근했던 데이터에 다시 접근할 때 디스크에 접근하지 않고 메모리에서 데이터를 읽음으로써 빠른 처리가 가능.

      ■ 일반 블록 계층 (Generic Block Layer)
       : 
    시스템 내 모든 블록 장치에 대한 요청을 다루는 커널 구성 요소
       : 
    일반 블록 계층은 각 하드웨어 블록 장치의 특징들을 숨겨서 블록 장치에 대한 추상적인 관점을 제공
       : 
    실제 입출력 연산을 위해 하위 구성 요소에 필요한 모든 정보를 준비하는 계층.

      ■ 
    I/O Scheduler Layer
       : 
    일반 블록 계층에서 넘어온 입출력 전송 요청을 커널 정책에 따라 정렬하는 계층
       : 
    I/O 스케줄러의 목적은 서로 가까운 I/O 요청을 그룹화 시켜서 디스크 탐색 오버헤드를 줄이는 것

      ■ (Block) Device Driver
       : I/O 스케줄러가 큐잉한 I/O 요청을 처리하는 계층. 요청을 해석하여 디스크 컨트롤러의 하드웨어 인터페이스에 적당한 명령을 보냄
       : 하드웨어(디스크) 인터럽가 발생했을 시 이를 처리할 수 있는 인터럽트 핸들러가 있음
     
      ∴ 각 계층 구조 동작

      



'Major > Linux' 카테고리의 다른 글

리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (6) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
리눅스 - 기초  (0) 2016.01.28
내장형 시스템 - 하드웨어  (0) 2016.01.26
  • System Call?




    - System Call Number


    - System Call 처리 과정




  • System Call 구현
    : "두 개의 정수 값을 더하여 결과 값을 반환"하는 System Call 구현









'Major > Linux' 카테고리의 다른 글

리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (6) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
리눅스 - 기초  (0) 2016.01.28
내장형 시스템 - 하드웨어  (0) 2016.01.26
  • 리눅스 커널 구조


    - 커널 구조에 따른 운영체제 구분
    ■ Monolithic 구조
      

     Micro-Kernel 구조
     

     

  • 리눅스 부팅 과정
      

  • Directory 구조
    : 리눅스 디렉토리 구조는 리눅스 커널의 소스 구조와는 다름
    - 리눅스 디렉토리 구조





    - 커널 소스 트리 구조



  • 리눅스 기본 명령어
    :파일 관련압축 관련프로세스/시스템 관련

    기능

    사용법 

    예시 

     파일 목록 출력

     ls [option]

     ls 
     ls -al

     현재 디렉토리에서 다른 디렉토리로 경로 변경

     cd 디렉토리 
     cd /디렉토리

     cd / ,cd .. 
     cd Downloads

     파일을 다른 파일명 또는 다른 디렉토리로 복사

     cp [option] source_file destination_file

     cp [option] source_file destination_directory

     cp -r Downloads backup

     파일을 다른 디렉토리로 이동하거나 다른 이름으로 변경

     mv [option] source_file destination_file

     mv [option] source_file destination_directory

     mv -i Downloads/helloworld.c backup

     파일 삭제

     rm [option] file

     rm [option] source_file destination_directory

     rm *
     rm -r backup, rm -i Downloads/helloworld.c

     새로운 디렉토리 생성

     mkdir [option] directory_name

     mkdir sub1 sub2 sub3

     디렉토리 삭제 rmdir [option] directory_name rmdir sub1
     현재 디렉토리명 표시 pwd [option]  
     텍스트 파일의 내용 출력 cat [option] file  cat etc/default/grub
     텍스트 파일의 내용을 화면에 한 페이지씩 출력 more [option] file  Space - 다음 페이지 출력, b - 이전 페이지로 이동
     q - 출력 중지 
     빈 파일을 생성하거나 파일의 수정 시간 변경 touch [option] file  touch test_file 
     리눅스 파일 권한 변경 chmod [options] mode[,mode] file1 [file2 ...]

     chmod 777 Downloads/helloworld.c
     chmod -R 707 /bin/su
     여러 파일이나 디렉토리를 묶거나 푼다.
     
     tar [option] file [directory]
        -c : 하나의 파일로 묶기
        -x : 묶인 파일 풀기
        -v : 파일을 묶거나 풀 때 진행 과정을 상세히 표시
        -t : 묶음 파일에 있는 내용 표시. 실제 묶음 파일을 풀지 않는다.
        -f : 묶음 파일명 .tar 명령어를 사용할 때 반드시 사용
        -z : gzip 관련하여 압축/복원을 동시에 수행 
     tar cvf test.tar test
     tar xvf test.tar (압축 기능은 없다)
     tar xvfz test.tar
     tar tf test.tar
     파일 압축/해제 유틸리티 – 압축 후 파일 확장자는 .gz가 붙는다 gzip [option] file
     gunzip [option] file
     gzip test.tar
     현재 진행 중인 프로세스에 대한 정보 출력 ps [option]   ps -efu
     현재 실행 중인 프로세서의 시스템 자원 사용 현황 표시 top [option] 
     실행 중인 프로세스를 종료 kill [option] process ID  kill -9 4647
     다른 사용자 계정으로 로그인 su - [login ID] [option]  su -
     su - swmem
     다른 계정의 권한이 요구될 때, 그 계정으로 직접 로그인하지 않고 해당 계정의 권한으로 작업을 수행  sudo command
     sudo -u user_name command
     sudo vi /etc/shadow
     시스템을 종료할 때 일반적으로 사용되는 명령
     시스템 리부팅
     shutdown [option] time [message]
     shutdown now
     reboot

  • Make Utility




'Major > Linux' 카테고리의 다른 글

리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (6) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
리눅스 - 기초  (0) 2016.01.28
내장형 시스템 - 하드웨어  (0) 2016.01.26
  • Functional Diagram
  • 하드웨어 구조


    - 프로세서
     
     

      Embedded System에 적합한 프로세서 구조는? RISC
      : 로드-스토어(Load-Store) 아키텍처 프로세서는 보통 레지스터 안에 저장되어 있는 데이터를 이용하여 어떤 동작을 수행한다. 메모리에서 레지스터로 데이터를 읽어들일 때에는 로드 명령어를, 레지스터에서 메모리로 데이터를 저장할 때에는 스토어 명령어를 사용한다. 메모리를 액세스하기 위해서는 비용이 들기 때문에, 메모리를 여러 번 액세스하는 대신, 레지스터 안에 저장되어 있는 데이터를 여러 번 사용하는 식으로, 데이터 처리 동작과 메모리 액세스를 분리하는 것이 좋다.

      : CISC는 하드웨어의 복잡도에 초점을 맞추고 있고, RISC는 컴파일러의 복잡도에 초점을 맞추고 있다.

      
      : 이러한 설계 방식은 RISC 프로세서를 더욱 단순화시켜, 결론적으로 더 빠른 클럭으로 동작할 수 있게 되었다. 반면 전형적인 CISC 프로세서는 좀더 복잡하고, 좀더 낮은 클럭으로 동작한다. 하지만 지난 20년 동안, CISC가 RISC의 개념을 조금씩 적용함에 따라, RISC와 CISC 사이의 구분이 점점 모호해지고 있다.

      
     

    ■ 레지스터
      

      
     ■ 연산 장치 (ALU: Arithmetic & Logic Unit)
      
     
     ■ 제어 장치 (CU: Control Unit)
      

     ■ 버스 (Bus)

      

    - 메모리

      : 프로그램과 데이터를 저장하기 위한 공간
     
     


      



      ■ 주기억 장치
       : 프로그램이 실행되는 동안 프로그램과 데이터 저장
       : DRAM이 주로 사용

      ■ 보조 기억 장치
       : 주기억 장치보다 빈번하게 사용되지 않는 프로그램과 데이터 저장
       : HDD, SD, MMC

      ■ Cache
       : 주기억 장치의 접근 속도를 빠르게 하기 위해서 프로세서 주변에 배치된 소용량의 메모리
       : 프로세서가 읽고자 하는 명령이나 데이터를 최대한 빨리 프로세서에 전달하는데 목적
       : Data Inconsistency 발생 가능
       : SRAM이 주로 사용
       



      ■ Flash Memory


       



    - 입/출력 장치

      


     


      ■ Interrupt
      : Interrupt Latency? Interrupt가 발생했을 때부터 프로세서가 관련 ISR을 수행하기 시작할 때까지 걸린 시간
      : Interrupt Nesting? Interrupt는 비동기 이벤트이기 때문에 여러 개의 Interrupt가 동시에 발생할 수 있음, 모든 Interrupt에 대해 우선 순위를 정의해두고 높은 순위를 가지는 Interrupt를 낮은 순위의 Interrupt보다 우선적으로 처리

      
       


       


       



      ■ DMA (Direct Memory Access)

       : 같은 Bus를 사용할 경우 충돌 가능성

      



      ■ UART (A Universal Asynchronous Receiver/Transmitter)

      



      ■ GPIO (General Purpose I/O)
      



    - System Bus
      : Bus Handshaking
      : Wait Signals
      : Wait States
      ■ Architecture[폰-노이만(Von-Neumann) vs 하버드(Harvard Architecture)]
     

     



'Major > Linux' 카테고리의 다른 글

리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (6) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
리눅스 - 기초  (0) 2016.01.28
내장형 시스템 - 하드웨어  (0) 2016.01.26

+ Recent posts