이동통신 각종 식별번호 개념잡기(IMSI, MSISDN, MIN등)

참고: TTA 용어사전 (http://word.tta.or.kr/)

IMSI (International Mobile Station Identity), 국제 이동국 식별 번호   
GSM 서비스 가입 시에 이동 단말기에 할당되는 고유 15자리 식별 번호. 이 번호는 이동 국가 코드, 이동 네트워크 코드, 이동 가입자 식별 번호 및 국가 이동 가입자 식별 번호로 구성된다. IMSI는 다음과 같은 구조를 지닌다.

 

 

TMSI (Temporary Mobile Subscriber Identity), 임시 이동 가입자 식별 번호   

이동 통신 시스템에서 이동국을 식별하는 임시 식별 번호. 임시 식별 번호는 홈 위치 레지스터(HLR)의 인증 센터(AC/Auc)에 의해 부여되며, 이동국과 이동 전화 교환국(MSC) 사이에서 보안상 국제 이동국 식별 번호(IMSI: International Mobile Station Identity) 대신 사용된다.

이는 Air 인터페이스 상에 IMSI 노출을 최소화하기 위하여 최초 위치 등록시 IMSI 대신에 TMSI를 가입자별로 핟당한다.

가입자 식별을 보호하기 위해 인증과 암호화를 거쳐 이동국에 전송되며, 이동국 통신권 내에서 유효하고 통신권 외에서는 추가적으로 위치 영역 식별(LAI: Location Area Identification)이 필요하다.

특정 기능이나 정보의 접근을 위해 모든 GSM 기반 전화기에서 사용되는 코드로, PIN은 가입과 동시에 제공한다.

1. 파일 시스템

파일 시스템이란 운영제제가 파일을 시스템의 디스크상에 구성하는 방식을 말한다. 운영체제는 시스템의 디스크 파티션상에 파일들을 연속적이고 일정한 규칙을 가지고 저장하는데 파일 시스템은 이러한 규칙들의 방식을 제시하는 역할을 한다. 또한 파일 시스템은 시스템 디스크나 파티션 그라고 파일 시스템의 형식을 말할 경우에도 쓰일 수 있다. 파티션과 파일 시스템은 다른 것이다. 파일 시스템은 파티션을 구성해 주는 역할을 한다. 파일 시스템을 포함하지 못한 파티션은 파일 시스템을 사용될 수 있도록 초기화되고 파일 정보를 기록하기 위한 형식을 만들어야 한다. 이 과정을 거쳐야 파티션은 파일 시스템으로 사용될 수 있다.

1.1 파일 시스템의 구조

◎ 슈퍼블록(super block)
슈퍼블록(Super Block)은 파일 시스템에 의존하는 정보를 가지며 파일 시스템의 크기 등과 같은 파일 시스템의 전체 적인 정보를 가지고 있다.

◎ 아이노드(inode)
아이노드(inode)는 파일의 이름을 제외한 해당 파일의 모든 정보를 가지고 있다. 파일 이름은 inode 번호와 함께 디렉토리 안에 저장된다.

◎ 테이터 블록(data block)
데이터 블록(data block)은 inode에 포함된다. inode가 몇 개의 데이터 블록을 포함하고 있다. 데이터 블록은 파일에서 테이터를 저장하기 위해서 사용된다.

◎ 디렉토리 블록(Directory Block)
파일 이름과 inode번호를 저장하기 위해서 사용된다.

◎ 간접 블록(Indirection Block)
간접블록은 추가적인 테이터 블록을 위한 포인터들이 사용할 동작으로 할당되는 공간이다. 실제적으로 inode는 적은 수의 테이터 블록을 가지고 있다. 그러므로 더 많은 데이터 블록이 필요할 경우 이를 지정할 포인터가 필요하게 되는데 그때 포인터들이 사용할 동적인 블록이 간접 블록이다.

◎ 홀 (Hole)
홀은 inode나 간접 블록안의 테이터 블록의 주소로 특별한 값을 저장한다.홀은 파일 시스템에 의해서 파일안에 자리하게 된다. 하지만 이 홀을 위해 실질적으로 디스크 상에 공간은 할당되지 않는다. 단지 0바이트가 파일 안에서 특정 공간을 차지하고 있더라고 가정하는 것이다.

@ EXT2
◎ EXT2 아이노드
inode는 파일시스템의 가장 기본되는 단위이다. 또한 각각을 구분할 수 있는 고유 번호를 가지고 파일의 테이터가 어느 블록에 어느 위치에 저장되어 있는지, 파일에 대한 접근 권한, 파일의 최종 수정시간 그리고 파일의 종류등의 정보를 inode 테이블에 저장한다. 저장되는 정보는 모드, 소유자 정보, 크기, 타임 스템프, 테이터 블록이다. 모드(mode)에는 inode가 속한 파일에 대한 정보와 파일에 대한 접근 권한 정보가 저장된다. EXT2 에서 inode는 단지 하나의 파일, 디렉토리, 심볼릭 링크, 블록 장치, 문자 장치 등만을 나타낸다. 소유자 정보 (Owner Information)는 파일과 디렉토리에 대한 소유자와 그룹에 대한 식별자를 나타낸다. 소유자 정보를 사용하여 파일이나 디렉 토리에 대한 접근 권한을 관리 할 수 있다. 크기(size)는 파일의 크기 정보를 저장한다. 파일에 대한 크기 정보는 바이트 단위로 저장된다. 타임 스템프 (timestamps)는 inode가 생성된 시간과 최종적으로 수정을 가한 시간에 대한 정보를 저장한다. 데이터 블록(Data Blocks)은 inode가 지정하고 있는 데이터 블록에 대한 포인터를 저장한다. 데이터블록에는 총 15개의 포인터가 존재하는데 이 포인터들 중에서 선행의 12개 포인터는 해당 inode가 지정하고 잇는 데이터에 대한 실제 블록에 대한 포인터 정보를 가지고 있다. 나머지 3개의 포인터는 높은 수준의 간접 연결에 대한 정보를 가지고 있다. inode 또한 실제로 존재하지는 않지만 시스템의 장치에 접근할 수 있는 특별한 장치 파일의 표현에도 사용된다. 리눅스 시스템의 /dev 디렉토리 안에 위치하는 파일들이 그것들이다.

◎ EXT2 슈퍼블록
슈퍼블록(Super Block)은 해당 파일 시스템의 기본적인 크기나 형태에 대한 정보를 저장한다. 파일 시스템 관리자는 이 슈퍼 블록의 정보를 이용하여 파일 시스템을 활용하고 유지할 수 있다. 슈퍼 블록에 저장되는 정보의 항목은 다음과 같다. 매직 넘버(Magic Number)는 마운트하는 소프트웨어에게 EXT2파일 시스템의 슈퍼 블록임을 확인 하게 하는 값이다. 개정 래벨(Revision Level)개정 래벨은 메이저 레벨과 마이너 래벨로 구성되어 있음 개정 래벨의 역할은 마운트 프로그램이 어떤 특정한 버전에서만 지원되는 기능이 이 파일 시스템에서 지원되는지에 대한 확인을 위해 사용된다. 또한 개정 레벨은 기능 호환성 항목을 포함하여 마운트 프로그램이 해당 파일 시스템에서 안정적으로 사용할 수 있는 기능이 무엇인지를 판단할 수 있는 기준을 제공한다.파운트 횟수(Mount Count)와 최대 마운트 횟수(Maximum Mount Count)의 두 가지 정보를 이용하여 파일 시스템 전체를 검사할 필요가 있는지를 확인할 수 있다. 마운트 횟수는 마운트가 실행될 때마다 1씩 그 값이 증가하여 만약 마운트 횟수가 최대 마운트 횟수에 도달하게 되면 시스템은 e2fsck를 실행하라는 메시지를 내보낸다.블록 그룹 번호(block Group Number)는 슈퍼 블록 복제본을 가지고 있는 블록 그룹의 번호를 나타낸다.블록 크기(Block size)는 파일 시스템의 블록 크기를 바이트 단위로 표시한다.그룹 당 블록수(Blocks per Grop)는 하나의 그룹에 속한 블록의 수를 나타낸다.이 수는 블록의 크기와 마찬가지로 파일 시스템을 만들 때 결정된다. 프리 블록(Free Block)파일 시스템 내부적으로 존재하는 프리 블록의 수를 나타낸다. Free inode 파일 시스템 내부적으로 존재하는 Free inode 수를 나타낸다. 첫 inode (Frist inode)파일 시스템 내부적으로 존재하는 첫번째 inode 번호를 나타낸다. 리눅스 시스템에서 첫 번째 inode는 "/"디렉토리에 디렉토리 엔트리를 나타낸다.

◎ EXT2 그룹 기술자(Group Descriptor)
그룹기술자는 블록 그룹에서 블록의 할당 상태를 나타내주는 비트맵으로 그 수는 블록의 수와 동일하다.블록 비트맵은 블록을 할당하거나 해제할 경우 참고 되는 정보다.그룹 기술자에 저장되는 항목은 블록비트맵, inode 비트맵, inode 테이블이다.블록 비트맵(Block Bitmap)은 블록 그룹에서 블록의 할당 상태를 나타내주는 비트맵으로 그 수는 블록의 수와 동일하다 블록 비트맵은 블록을 할당하거가 해제 할 경우 참고되는 정보다. inode 비트맵(inode Bitmap)은 블록 그룹에서 블록의 inode 할당상태를 나타내 주는 비트맵으로 그 수는 블록 비트맵과 같이 블록의 수와 동일하다. inode 비트맵은 inode를 할당하거나 해제할 경우 참고 되는 정보이다. inode 테이블(inode Table)은 블록 그룹의 inode 테이블에서 시작 블록을 나타내며 그 수는 블록의 수와 동일하다.이외에도 프리 블록 개수,프리 inode 개수,사용된 디렉토리 개수가 있다.그룹 기술자는 연속적으로 나타나서 전체적으로 하나의 그룹 기술자 테이블을 형성하게 된다. 각 블록 그룹에는 슈퍼블록 바로뒤에 그룹 기술자 테이블 전체가 위치 하게 된다.하지만 실제로 EXT2 파일 시스템에서 사용되는 블록 그룹이'0'인 첫 번째 복사본이다. 나머지는 예상치 못한 시스템의 손상에 대비해 시스템 복구를 위해 준비하고 있을 뿐이다.

◎ EXT2 디렉토리
EXT2파일 시스템에서 디렉토리는 파일에 대한 접근 경로를 생성하고 저장하는 특별한 의미의 파일로 취급된다.
디렉토리는 엔트리의 리스트로 나타내어 지며,엔트리 리스트에 저장되는 정보는 inode,이름길이,이름이다.
inode는 디렉토리 엔트리에 해당하는 inode를 나타낸다. inode 값은 블록 그룹의 inode 테이블에 저장되어 잇는 inode 배열에 대한 인텍스 값이다.이름 길이(Name Length)는 디렉토리 엔트리의 길이를 바이트로 나타낸것을 의미한다.이름(name)은 디렉토리의 이름을 나타낸다. EXT2파일 시스템에서 모든 디렉토리에서 처음 두 엔트리는 항상 "."과".."으로 시작한다 "."은 현재 디렉토리를 의미하며,".."은 상위 디렉토리인 부모 디렉토리를 의미한다.

@ EXT3
◎ EXT3로 포팅 동기
기존의 EXT2는 캐시에 저장되어 있는 테이터들을 디스크로 저장하는 도중 만약 시스템이 다운되거나 여러 가지 문제가 발생할 경우 파일 시스템이 손상되는 단점을 가지고 있었다. 이를 위해 EXT2는 fsck(File System Check)라는 파일 시스템 복구 기능을 제공한다. 하지만 이 복구 방법은 복구하는데 시간이 만이 소요되는 문제점을 가지고 있다. 파일 시스템의 크기가 크다면 복구하는데 오랜 시간이 걸릴 뿐만 아니라 복구하는 동안시스템을 사용하지 못한다. 또한 슈퍼 블록에 마운트 횟수를 저장하는 영역이 있어서 마운트 횟수가 일정횟수 이상이 될경우에도 자동으로 fsck를 실행하게 된다. EXT3파일 시스템은 이러한 단점을 보안하기 위해서 저널링(Journaling)이라는 기능을 추가 해서 소개된 파일 시스템이다. 시스템의 무결성은 물론 뛰어난 복구 기능까지 가질수 있게 되었다. 또한 EXT2는 기능적인 측면보다는 파일 시스템의 휴율과 퍼포먼스에 중점을 두고 디지안된 파일 시스템이다. 그래서 EXT2는 파일의 내용과 파일에 대한 허가권, 소유권, 생성과 접근 시간과 같은 메타 데이터를 동기화 하지 않는다. 이럴경우 방생하는 문제는 파일의 내용을 수정도중 시스템의 문제가 생길 경우 해당 파일의 메타 데이터와 내용이 일치 하지 않는 문제점이 발생한다. 이것을 보안한 것이 저널링 기술을 이용한 EXT3 파일 시스템이 대두한 것이다.

◎ 저널링(Journaling)기술이란?
데이터를 디스크에 쓰기 전에 로그에 데이터를 남겨 시스템의 비정상적인 셧다운에도 로그를 사용해 fsck보다 빠르고 안정적인 복구기능을 제공하는 기술이다. 기존 EXT2 파일 시스템의 경우에는 시스템이 동작을 멈추기 바로 직전에 파일 시스템에 어떤한 수정을 가하고 있었는지 전혀 알 수 없다. 때문에 복구하기 위해서는 fsck에 의해서 관리되는 슈퍼 블록, 비트맵, inode 등을 모두 검사해야 하기 때문에 시간이 오래 걸렸다. 저널링 기술은 사용한 파일 시스템의 경우 파일을 실제로 수정하기 전에 우선 로그에 그 수정된 내용을 저장하기 때문에 복구하기 위해서 로그만 검사하면된다. 로그를 바탕으로 다시 실제 파일 시스템에 수정 내용을 적용하기 때문에. 속도와 복구 안정성이 더욱 뛰어나다. 이런한 동작 수행을 리플레이(Replay)이라고 한다. 만약 해당 로그에 저장된 내용이 불안정할 경우에는 복구 자체를 포기하기 때문에 파일 시스템이 불안정한 상태로 되지 않는다. 파일 시스템에 수정을 가하기 전에 우선 로그에 저장하는 이러한 파일 시스템의 특성 때문에 Log-Ging 파일 시스템이라 부르기도 한다.

◎ 저널링 파일 시스템의 구조
저널링 파일 시스템의 구조는 로그 영역과 일반적인 파일 시스템 영역으로 나눌 수 있다. 로그 영역은 파일 시스템에 대한 수정을 위한 로그 데이터를 저장하기 위해 그리고 파일 시스템영역은 관리 영력과 테이터 영역으로 구성되어 있다. 저널링 파일 시스템은 일반 적인 파일 시스템에 로그 영역을 추가 한 구조이므로, 저널링 기능을 제거하고 일반적인 파일 시스템과 같이 사용할 수도 있다. 로그(Log)는 원형의 버퍼 구조 형태로 순환적으로 데이터들이 저장된다. 버퍼의 끝에 도달하면 데이터들은 다시 버퍼의 가장 앞쪽에 저장되는 구조이다. 로그상에는 테이터를 지정하는 포인터가 존재하여 테이터를 구분할 수 있다. 로그의 내용은 계속해서 수정되는 파일 시스템에 대한 로그 레코드가 추가되어 갈 뿐 일반적인 파일 시스템운영에서는 로그에 대한 읽기와 쓰기 같은 접근은 이루어 지지 않는다. 로그는 원형의 버퍼와 같은 구조로 되어 있기 때문에 시간이 지나면 포화 상태가 된다. 그러므로 로그 영역이 포화가 되면 가장 오래된 로그 레코드 순으로 삭제하는 동작을 수행해야 한다. 삭제의 수행은 실제 파일 시스템에 적용되 레코드들이 포함된다. 로그 레코드에 대한 삭제를 위한 전용 스레드에 의존한다. 적잘한 관리가 이루어지지 않으면 로그의 빈공간을 찾아 기다리게 되어 I/O수행이 느려질 수도 있다. 트랜잭션은 저널링 파일 시스템에서 로그에 내용을 저장하는 수행단위다. 파일 시스템의 일정한 조작에 대한 파일 시스템 내부적인 일련의 동작 수행이다. 저널링 파일 시스템은 디스크의 빈 블록 비트맵이나 inode가 포함된 블록에 대한 수정을 하기 전에 반드시 로그에 대한 트랜잭션을 수행한다.
트랜잭션의 수행을 단계별로 보면
트랜잭션 할당 단계 - 수행할 파일 작성 트랜잭션에 대한 ID를 획득하기 위해서 새로운 트랜잭션 할당을 수행한다.
트랜잭션 추가 단계 - 디스크상의 블록을 변경하기 전에 반드시 로그에 기록해야하기 때문에 트랜잭션별로 할당되어 있는 관리 데이터와 링크되어 메모리에 저장된다. 이 단계는 아직 로그에 저장된 상태는 아니다. 단지 트랜잭션에 로컬로 저장된 상태이다.
트랜잭션 위탁 단계 - 트랜잭션 추가 단계에서 만들어진 트랜잭션의 내용을 로그에 저장하는 동작을 수행한다. 위탁과 함께 롤백이라는 동작도 수행되는데 롤백은 트랜잭션 중에서 수행한 수정을 취소할 경우 수행되는 것으로 에러가 발생했을 경우에도 수행된다.


1.2 파일 시스템의 종류

리눅스는 다양한 파일 시스템을 지원한다. ext2, ext3, minix, xiats, umsdos, hpfs OS/2, isofs, CD-ROM, msdos, nfs, sysv 등이 있다. 이 파일 시스템들은 각각 다음과 같은 특징을 가지고 있다.

◎ minix
과거 미닉스에서 사용되어졌던 파일 시스템으로 리눅스 파일 시스템 대부분의 기능을 제공하는 파일 시스템이다.

◎ xiafs
미닉스의 제한이 이었던 파일 이름과 파일 시스템에 대한 제한을 보안한 미닉스 파일 시스템의 수정 버전이다. 이 파일 시스템에는 추가된 새로운 기능은 없다. 한때 ext2와 함께 사용되었던 파일 시스템이었으나 현재는 많이 사용되지 않는다.

◎ msdos
도스의 FAT파일 시스템과 호환을 지원하는 파일 시스템이다. 또한 msdos와 OS/2와 윈도NT FAT파일 시스템과도 호환된다

◎ hpfs OS/2
OS/2의 파일 시스템이다. 하지만 현재는 읽기 전용인 파일 시스템으로 파일 시스템에 대한 읽기만이 가능하다.

◎ isofs CD-ROM
ISO기준을 따르는 표준 CD-ROM의 파일 시스템이다. isofs CD-ROM은 CD-ROM에 좀더 긴 파일명을 사용할 수 있도록 확장된 록 브릿지가 기본으로 지원된다.

◎ umsdos
MS-DOS 파일 시스템을 리눅스 상에서도 긴 파일명과 소유자, 접근 허가, 링크와 장치 파일 등을 사용할 수 있도록 확장한 파일 시스템이다. umsdos는 일반적으로 DOS 파일 시스쳄이 마치 리눅스 파일 시스템인 것처럼 보이도록 하는 기능을 제공하므로 따로 리눅스를 위한 파티션은 필요하지 않는다.

◎ nfs
네트워크 파일 시스템이다. 네트워크 상의 많은 컴퓨터들이 각각의 시스템에 가진 파일들을 서로 쉽게 공유하기 위해 제공되는 상호간의 파일 시스템 공유 파일시스템이다.

◎ sysv
System V/386, Xenix 그리고 Coherent 파일 시스템이다.

◎ ext
리눅스 초기에 사용되던 파일 시스템으로 호환성이 없던 ext2의 구 버전이다. 지금은 대부분 하지 않는다.

◎ ext2
리눅스는 미닉스 파일시스템을 처음으로 사용했다. 그러나 여러가지 제약 조건과 성능이 뛰어나지 못하였다. 이를 보안 하기 위해 EXT(Extened File System)이 제시 되었다. 이 파일 시스템은 리눅스 전용으로 설계되어 1992년 4월에 소개 되었다. 또한 1993년에는 2차 확장 파일 시스템인 EXT2가 ext의 여러가지 문제점을 보안하여 나왔다.


2. 디렉토리 구조

리눅스의 기본 디렉토리 구조는 트리 구조를 하고 있다. 그리고 디렉토리 구조는 기본구조를 제외하고 사용자의 설정에 따라 달라질 수 있다. 리눅스의 디렉토리 구조는 파일 시스템 표준안 (FSSTND, Linux File System Standard)을 기반으로 하는 것이 바람직하다. 파일 시스템 표준안은 리눅스상에서 어떻게 파일 시스템을 구성할 것인지에 대한 표준안을 제정하기 위해서 만들어진 문서이다. 표준안을 무조건 따르라는 강제력은 없지만 파일의 위치가 일관된게 유지되어 프로그램 작성, 포딩은 물론 시스템 관리도 쉬워지는 이점이 있기에 배포판들은 이 표준안을 지키고 있다.

2.1 디렉토리 기능 및 내용

대부분의 리눅스는 FHS(Filesystem Hierarchy Standard) 표준 파일 시스템 계층을 사용하고 같은 목적의 파일들은 같은 장소에 일관되게 모아 관리하므로 시스템에 자원이나 프로그램들을 쉽게 찾을 수 있다.

◎ /
루트 디렉토리라고 부르는 리눅스 시스템에서 가장 최상위 디렉토리며 디렉토리 구조의 시작이다. 시스템관리자의 홈인 /root와는 다르다. / 디렉토리 아래에 /bin, /etc, /boot, /mnt, /usr, /lib, /home, /dev, /proc, /var, /sbin, /tmp, /root, /lost+found 등의 디렉토리가 존재한다.

◎ /bin
binaries의 약어로 이진 파일들이며 리눅스에서 가장 기본이 되는 명령어들이 모여 있는 디렉토리이다. 디렉토리의 파일들을 보면 대부분이 실행 파일임을 알 수 있다. 또한 이곳에는 부팅에 필요한 명령어들이 위치하여 부팅후에 시스템의 계정 사용자들이 사용할 수 있는 일반적인 명령어들도 위치 하고 있다.

◎ /etc
이 디렉토리는 리눅스 시스템에 관한 각종 환경 설정에 연관된 파일들과 디렉토리들을 가진 디렉토리이다. 대부분의 이 디렉토리의 파일들은 시스템 관리자에 의해 관리되는 파일들이다. 웹 서버 환경 설정, 시스템 계정 사용자 정보, 패스 워드 관리, 시스템의 파일 시스템 관리 파일, 여러가지 시스템 보안에 관련된 파일들, 시스템 초기화 설정 파일, TCP/IP 설정 파일 등 시스쳄 전반에 걸친 거의 모든 환경 설정 파일들이 모두 이 디렉토리에 있다.

◎ /etc/rc.d
시스템의 부팅과 시스템 실행 레벨 변경시에 실행되는 스크립트들이 저장되어 있는 디렉토리이다. 리눅스의 6가지 실행 레벨로 각각의 해당 디렉토리가 있다.

◎ /etc/shadow
파일에서 패스워드 부분만을 따로 저장하는 파일이다. 이 파일에 패스워드는 암호화 되어 셰도우 패스워드 형태로 저장되어 있으며 시스템 관리자만이 접근할 수 있기 때문에 크래킹 등에 대한 우려가 상대적으로 적다.

◎ /etc/group
시스템의 그룹에 대한 정보를 저장하고 있는 파일이다.

◎ /etc/inittab
init를 설정하는 파일이다.

◎ /etc/issue, /etc/issue.net
getty에 의해서 로그인을 위한 프롬프트가 뜨기 전에 출력되는 메시지를 설정하는 파일이다. 리눅스 시스템으로 접속할 경우 가장 처음으로 볼 수 있는 메시지이다. 보통 시스템에 대한 설명과 각종 환영 메시지를 전달하기 위해서 사용된다. issue 파일의 내용은 보통 시스템의 터미널에서 볼 수 있다. 그리고 /etc/issue.net 파일의 내용은 리모트상에서 시스템으로 접속할 경우 볼 수 있다.

◎ /etc/motd
'Message of the day'의 약자로 시스템으로의 접속에 성공할 경우 쉘이 뜨기 전에 출력되는 메세지를 설정하는 파일이다.

◎ /etc/profile, /etc/csh.login, /etc/csh.cshrc
시스템이 시작될 때 사용자가 로그인을 할 때 본쉘이나 C쉘에 의해서 실행되는 스크립트 파일이다. 일반적으로 사용자들에 대한 기본 환경 설정에 사용된다.

◎ /etc/securetty
시스템 관리자가 시스템에 로그인할 수 있는 안전한 터미널에 대한 정보가 저장되어 있다. 일반적으로 가상콘솔이 설정되어 있다. 이것은 네트워크를 통해 시스템으로 침입해 시스템 관리자의 권한을 획득하는 크랙킹을 막기 위해서이다.

◎ /ete/shell
시스템에서 안정적으로 사용할 수 있는 쉘에 대한 정보를 저장하고 있는 파일이다. 만약 chsh명령을 사용해 사용중인 쉘을 바꾸려면 이 파일에 저장되어 있는 쉘중에 선택해야한다. 또한 ftp데몬의 경우 사용자의 쉘을 검사하여 /etc/shell에 저장되어 있지 않은 쉘을 사용한다면 로그인을 허용하지 않는다.

◎ /boot
리눅스 커널이 저장되어 있는 디렉토리로서 각종 리눅스 boot에 필요한 booting지원 파일들이 저장되어 있는 디렉토리이다.

◎ /mnt
외부 장치인 플로피 디스크, 시디롬, 삼바등을 마운트하기 위해서 제공되는 디렉토리이다. 임시로 사용되는 디렉토리이므로 프로그램들은 /mnt에 어떤 파일 시스템이 마운트 되었는지 자동으로 인식하지 않는다. 또한 /mnt는 보통 여러 개의 하위 디렉토리로 나누어 사용되고, 평소에는 각 디렉토리들은 비어 있다.

◎ /usr
시스템에 사용되는 각종 프로그램들이 설치되는 디렉토리이다. 프로그램과 관련된 명령어 미치 라이브러리들이 이 디렉토리에 위치 하게 된다. 또한 X 시스템관련 파일들과 리눅스 커널 소스, 각종 C언어 과련 해더 파일 등도 이 디렉토리 안에 저장되어 있다.

◎ /usr/bin
리눅스 시스템에서 사용되는 각종 프로그램들이 저장되어 있으며 /bin 디텍토리에 없는 다양한 실행 파일들이 저장되어 있는 디렉토리이다.

◎ /usr/X11R6
X 윈도우 시스템에 사용되는 모든 파일들이 이 디렉토리 안에 저장된다. 이 디렉토리는 X 윈도우 시스템의 개발과 설치를 좀더 쉽게 하기 위해서 전체 시스템 디렉토리 구조에 통합되지 않고 독자적인 구조를 가진다.

◎ /usr/etc
/etc 디렉토리에는 각종 환경 설정 파일들이 있듯이 이곳에도 여러 가지 시스템 환경 설정 파일들이 저장되어 있다./usr/etc의 파일들은 /etc디렉토리 안의 파일들과 달리 꼭 팔요한 파일들은 아니다.

◎ /usr/sbin
시스템 관리자를 위한 명령어들이 저장되는 디렉토리이다. 보통 이 디렉토리의 명령어들은 루트 파일 시스템에는 필요가 없는 서버 프로그램들이 저장된다.

◎ /usr/include
C언어 관련 해더 파일드이 저장되어 있는 디렉토리이다.

◎ /usr/lib
각종 라이브러리들이 저장되어 있는 디렉토리이다. 만약 사용자가 직접 작성한 프로그램을 컴파일한다면 해당 프로그램은 /usr/lib 디렉토리의 파일에 link된다. 또한 이 라이브러리 안에 실행 코드가 필요하다면 /lib 디렉토리를 참조한다.

◎ /usr/local
시스템의 특정적인 프로그램들이 저장되는 디렉토리이다.특정적인이란 시스템 관리자에 의해서 따로 설치되는 프로그램들을 말한다.

◎ /usr/man
man페이지의 실제 내용들이 저장되어 있는 디렉토리이다. 디렉토리를 살펴보면 man1, man2, man3, 등과 같이 여러개의 디렉토리들로 나누어져 있는 모습을 볼수 있다.man1 디렉토리는 섹션 1의 man 페이지 소스를 위한 디렉토리를 말한다.

◎ /usr/src
시스템에서 사용하는 각종 프로그램들의 컴파일되지 않은 소스 파일들이 저장되어 있다./usr/src/linux 디렉토리가 바로 리눅스의 커널소스를 저장하고 있는 디렉토리이기 때문이다.

◎ /usr/X386
/usr/X11R6 디렉토리와 유사한 티렉토리로 X11 Release 5를 위한 디렉토리이다.

◎ /usr/info
GNU info문서들을 저장하고 있는 디렉토리이다.

◎ /usr/doc
각종 문서들이 저장되어 있는 디렉토리이다

◎ /lib
프로그램들의 각종 라이브러리들이 존재한다. 대부분 공유 라이브러리로 더 편하게 사용할 수 있으며,파일의 크기를 줄여서 실행할 때 불러 사용하게 된다. /lib/modules 디렉토리에는 커널로 로딩 사능한 커널 모듀들이 저장되어 있다.

◎ /home
시스템 계정 사용자들의 홈 디렉토리와 ftp,www,등과 같은 서비스 디렉토리들이 저장된다. 이곳의 디렉토리와 파일들은 시스템에서 상용되지 않는다. 단지 리모트상에서 시스템으로 접속하는 사용자들을 위한 공간이다.

◎ /dev
디렉토리에는 시스템의 각종 디바이스들에 접근하기 위한 디바이스 드라이버들이 자장되어 있는 디렉토리이다. 이 디렉토리는 물리적인 용량은 갖지 않는 가상 디렉토리이다. 대표적으로는 하드 드라이브,플로피, 씨디롬 그리고 루프팩장치 등이 존재한다. 리눅스 시스템은 윈도우와 달리 각종 디바이스 장치들을 하나의 파일로 취급한다. 따라서 시스템은 각각의 장치들로부터의 정보를 /dev 디렉토리에 존해하는 해당 장치 파일로 부터 가지고 온다.

◎ /dev/console
시스템의 콘솔이다.

◎ /dev/hda
시스템의 하드 디스크이다. 여기서 /dev/hda는 첫 번째 하드 디스크를 의미하는 것이다./dev/hda1은 첫번째 하드 디스크의 첫번째파티션,/dev/hda2 두 번째 파티션등을 의미한다.만약 시스템에 여러 개의 하드 디스크가 부착되어 있다면 /dev/hdb,/dev/hdc 등의 파일도 /dev/hdb1,/dev/hdb2등과 같은형식으로 저장되어 있다.

◎ /dev/lp
시스템의 병렬 포트 장치들이다.

◎ /dev/null
이 디렉토리는 블랙홀이라고도 부르는 특별한 장치이다. 이 장치로 데이터 등을 보내면 모두 폐기되므로 주의해야 할 것이다.

◎ /dev/pty
시스템으로의 원격 접속을 위한 'pesudo-terminal'들이다. 만약 시스템 계정 사용자드이 원격지에서 시스템으로 텔넷등을 이용하여 시스쳄에 접속을 시도한다면 이들은 /dev/pty 디바이스들을 사용하게 되는 것이다.

◎ /dev/sda
SCSI 장치들이다. 만약 시스템에 스카시 하드 디스크를 장착했다면 시스템은 /dev/sda파일에서 정보를 얻어 장치에 접근할 것이다.

◎ /dev/ttyS,/dev/cuaS
/dev/ttyS은 직렬포트 장치들이고, /dev/cauS는 Callout. 장치이다.

◎ /dev/tty
시스템의 가상콘솔들이다. 이 가상 콘솔의 기능은 하나의 화면에 여러 개의 콘솔들을 만든다. 만약 사용자가 시스템 앞에 앉을 수 있다면,Alt + F1, Alt + F2등을 이용하여 리눅스에 제공한 여러개의 가상 콘솔을 직접 볼수 있을 것이다.

◎/proc
시스템의 각종 프로세서, 프로그램 정보 그리고 하드웨어적인 정보들이 저장된다. 이 티렉토리는 가상 파일 시스템으로 가상 파일 /dev와 마찬가지로 하드 디스크상에 물리적인 용량을 갖지 않는다. 즉 디렉토리에 존재하는 파일들은 실제 하드 디스크에 저장되지 않고 커널에 의해 메모리에 적재 된다. 디렉토리 안의 파일들은 현재의 시스템 설정을 보여 주는 것이다.

◎ /proc/1
프로세스 번호가 1인 프로세스에 대한 정보를 저장하는 디렉토리이다. 다른 프로세스들도 자신의 고유한 프로세스 번호의 디렉토리를 가진다는 것을 의미한다.

◎ /proc/cpuinfo
프로세서의정보를 저장하고 있는 파일이다. cpu의 타입, 모델, 제조회사, 각종 성능 등의 정보를 제공하여 준다.

◎ /proc/devices
현재 시스템 커널에 설정되어 있는 장치들에 대한 정보를 저장하고 있다.파일등의 정보로 모든 시스템의 장치 목록에 대한 정보를 얻을 수 있다.

◎ /proc/dma
현재 시스템에서 사용하고 있는 DMA 채널에 대한 정보를 저장하고 있다.

◎ /proc/filesystem
시스템에 설정되어 있는 파일 시스템에 대한 정보를 저장하고 잇는 파일이다.

◎ /proc/interrupts
현재 사용중인 인터럽트와 인터럽트의 사용량에 대한 정보를 저장하고 있는 파일이다.

◎ /proc/ioports
현재 사용중인 I/O 포트에 대한 정보를 저장하고 있는 파일이다.

◎ /proc/kcore
현재 시스템에서 사용중인 메로리의 실제 이미지이다. 이 파일은 실제 메모리의 내용을 모두 가진 것처럼 보이지만 프로그램이 필요로 하는 부분의 이미지만을 필요할 때 만들어 제공한다.

◎ /proc/kmsg
커널에 의해서 출력되는 메시지들을 저장하고 있는 파일이다.이것은 또한 syslog파일에도 저장된다.

◎ /proc/loadavg
현재 시스템의 평균 부하량(Load Average)에 대한 정보를 저장하고 있는 파일이다.이 파일을 통해서 시스템이 현재 수행해야 하는 일이 얼마나 많은지를 알려주는 3가지 지표에 대한 정보를 얻을 수 있다.

◎ /proc/ksyms
시스템 커널이 사용하고 있는 심볼들에 대한 정보를 저장하고 있는 파일이다.

◎ /proc/meminfo
현재 시스템이 사용중인 메모리의 사용량을 저장하고 있는 파일이다./proc/meminfo에서 실제 메모리는 물론 가상 메모리에 대한 정보도 얻으 수 있다.

◎ /proc/self
이 디렉토리를 보고 있는 프로그램 자시의 프로세스 디렉토리로 링크도어 있다. 만약 서로 다른 2개의 프로세스가 /proc 디렉토리를 보고 있다면 두 프로세스는 서로 다른 링크를 보게 된다. 이를 통해서 프로그램들이 자신의 프로세스 디렉토리를 쉽게 찾을 수 있다.

◎ /proc/stat
시스템의 현재 상태에 대한 다양한 정보를 저장하고 있는 파일이다.

◎ /proc/uptime
시스템이 얼마나 오래 동작했는지에 대한 정보를 저장하고 있는 파일이다.

◎ /proc/version
시스템이 현재 사용중인 커널 버전에 대한 정보를 저장하고 있는 파일이다.

◎ var
시스템에서 사용되는 동적인 파일들이 저장된다. 각종 시스템 로그 파일, 사용자 로그인에 대한 보안기록,메일서버를 운영한다면 사용자들에게 전송된 메일들을 임시로 저장한다.

◎ /var/cache
포멧된 메뉴얼 페이지들이 잠시 대기(Cache)하기 위한 디렉토리이다.

◎ /var/lib
시스테이 동작하면서 계속 수정되고 변경되는 파일들을 위한 디렉토리이다.

◎ /var/local
/usr/local 디렉토리에 설치된 프로그램들의 각종 데이터들이 저장되는 디렉토리이다.

◎ /var/lock
잠금 파일들이 저장되는 디렉토리이다.프로그램들이 특정한 장치나 파일들을 프로그램 자신이 독점적으로 사용하려 할 때 /var/lock 디렉토리에 잠금 파일을 만들어 사용하게 된다. 그렇기 때문에 다른 프로그램들은 장치나 파일을 사용하기 전에 우선 이 디렉토리의 내용을 조사하여 해당 장치나 파일들이 사용중인지 확인하게 된다.

◎ /var/log
프로그램들의 로그 파일들이 저장되는 디렉토리이다. 이 디렉토리에 wtmp파일은 login 파일과 messages파일은 syslog의 로그 파일이다.wtmp는 시스쳄의 모든 사용자 로그인과 로그 아웃에 대한 정보르 저장하고 있는 파일이고,messages는 커널과 시스템의 모든 출력 메세지를 저장하고 있는 파일이다./var/log 안의 파일들은 시스템의 사용량에 따라 그 크기가 무한대로 증가할 있으므로 정기적으로 파이들을 삭제하는 등 디렉토리 관리가 필요하다

◎ /var/run
시스템의 현재 정보들을 저장하고 있는 디렉토리이다./var/run/xinetd.pid 파일의 경우 현재 사용중인 xinetd 데몬의 프로세스 번호를 저장하고 있다.

◎ /var/spool
메일이나 뉴스, 프린터 큐 등고 같은 시스템상에서 대기 상태에 있는 작업들을 위한 디렉토리이다. 각각의 대기 작업들은 모두 /var/spool 아래 고유의 디렉토리에 위치하게 된다. 예를 들어 시스템의 계정 사용자들의 메일은 /var/spool/mail 에 저장된다.

◎ /var/tmp
/tmp에 저장된 임시 파일들중에 오래 보관되어야 할 임시 파일들이 저장되는 디렉토리이다.

◎ /tmp
이름에도 알 수 있듯이 임시 파일들을 위한 디렉토리이다.

◎ /root
시스템 관리자의 홈 디렉토리이다

2005/11/28 12:24

http://blog.naver.com/jskim89/140019915656

< arch >
arch 서브디렉토리는 모든 아키텍쳐에 종속적인 커널코드를 포함하고 있다.
여기에는 서브디렉토리가 더 있는데, 각각 지원하는 아키텍쳐별로 있다.
예를 들어, i386, alpha 같은 이름의 서브디렉토리가 존재한다.

< include >
include 서브디렉토리는 커널코드를 빌드하는데 필요한 모든 include 파일의 대부분을 가지고 있다.
여기에는 지원하는 아키텍쳐별로 하나씩의 서브디렉토리가 있다.
/include/asm 서브디렉토리는 현재 아키텍쳐에 필요한 실제 디록토리로 소프트 링크 되어 있다.
(예를 들어, include/asm-i386)
아키텍쳐를 다른 것으로 바꾸려면 커널 makefile을 수정하고
리눅스 커널 환경 설정 프로그램으로 돌아와야 한다.
초기화 코드를 가지고 있으며, 커널이 어떻게 동작하는지 보기 좋은 곳이다.
< init >
이 디렉토리는 커널의 초기화 코드를 가지고 있으며,
커널이 어떻게 동작하는지 보기 시작하는 곳이다.

< mm >
이 디렉토리는 모든 메모리 관리 코드를 가지고 있다.
아키텍쳐 종속적인 메모리 관리 코드는 arch/*/mm/ 아래에 있따.
예를 들어, arch/i386/mmfault.c 같은 곳에 있다.

< driver >
모든 시스템의 디바이스 드라이버는 이 디렉토리에 있다.
이들은 디바이스 드라이버의 유형별로 좀 더 세분화되어 있다.
예를 들어, 블록 디바이스 드라이버는 block에 있다.

< ipc >
이 디렉토리는 커널의 프로세스간 통신 코드를 가지고 있다.

< modules >
이는 단순히 빌드된 모듈을 저장하기 위한 디렉토리이다.

< fs >
모든 파일시스템 코드를 가지고 있다.
파일시스템별로 하나씩 디렉토리가 세분화된다.
예를 들어, vfat, ext2 같은 서브디렉토리가 있다.

< kernel >
메인 커널 코드가 들어 있다.
아키텍쳐 종속적인 커널 코드는 arch/*/kernel에 있다.

< net >
커널의 네트워킹 코드가 들어 있다.

< lib >
이 디렉토리는 커널의 라이브러리 코드를 가지고 있다.
아키텍쳐 종속적인 라이브러리 코드는 arch/*/lib에 있다.

< scripts >
이 디렉토리는 커널을 설정하는데 사용되는 스크립트를 가지고 있다.
(예를 들어, awk나 tlk 스크립트)

리눅스 커널 소스 (The Linux Kernel Sources)

이 장은 특정 커널 함수를 찾기 위해서 리눅스 커널 소스 어디서부터 시작해야 하는지 이 야기한다.

이 책은 C 언어에 대한 지식을 요구하지는 않지만 리눅스 커널의 동작을 보다 잘 이해하려 면 리눅스 커널의 소스를 가지고 있는 것이 좋다. 다시 말하면, 커널의 소스 프로그램은 리 눅스 운영체제를 심도깊게 이해하는데 있어 효과적인 교재이다. 이 장은 커널 소스 전반에 대해 개괄한다. 즉 커널 소스가 어떻게 배열되어 있는지, 특정 코드를 찾으려면 어디서 시작 해야 하는지 설명한다.

어디서 리눅스 커널 소스를 얻을 수 있는가

주요 리눅스 배포판들(Craftworks, Debian, Slackware, Red Hat 등)은 모두 리눅스 커널 소스를 포함하고 있다. 일반적으로 사용자의 리눅스 시스템에 설치된 리눅스 커널은 이 소 스 코드를 컴파일하여 생성한 것이다. 리눅스의 성격상, 소스들이 계속 변경되므로 사용자의 시스템에 설치된 것은 조금 옛날 것이 되고 만다. 최신 버전의 소스 프로그램은 부록 B에 서 언급된 웹 싸이트에서 구할 수 있다. 이들은 ftp://ftp.cs.helsinki.fi과 이를 그 림자처럼 복사하는 다른 웹 싸이트에서 들어 있다. 헬싱키의 웹 싸이트가 가장 최신 버전의 소스를 가지고 있으며, MIT나 Sunsite와 같은 싸이트들로 비교적 최신 버전의 소스를 제공 한다.

웹 싸이트에 접근할 수 없다고 하더라도, 많은 벤더들이 주요 웹 싸이트에 있는 내용들을 CD ROM 형태로 매우 저렴한 가격으로 제공하고 있으므로, 이를 이용하면 될 것이다. 1년에 네번 혹은 매달 정기적으로 업그레이드판을 제공해주는 구독 서비스도 있다. 지역별 리눅스 유저 그룹도 소스를 구하는데 유용한 곳이다¹.

리눅스 커널의 버전 형태는 매우 단순하다. 짝수 버전 커널(예를 들자면 2.0.30)은 안정적 이고 발표된 버전이고, 홀수 버전 커널(예를 들자면 2.1.42)은 모두 개발용 커널이다. 본책 은 안정적인 2.0.30 소스 트리를 기반으로 하고 있다. 개발용 커널은 최신 기능들을 모두 포 함하고 있으며 또한 최신 드라이버들도 모두 지원한다. 개발 커널은 불안정할 수도 있고, 이 는 사용자가 바라지 않는 것이겠지만, 최신 커널을 사용해보는 것은 리눅스 공동체에 있어 중요한 일이다. 그래야 전체 공동체를 위해 테스트를 할 수 있다. 실제 제품으로 나온 커널 이 아닌 것을 써보려고 할 때 시스템 전체를 백업해두는 것이 좋다는 것을 기억하기 바란다.

커널 소스에서 바뀐 것들은 패치(patch) 파일로 배포된다. patch 프로그램은 소스 파일들에 편집된 것들을 적용하는데 사용된다. 따라서, 예를 들어 2.0.29 커널 소스를 가지고 있고, 이 를 2.0.30 소스로 바꾸고 싶다면, 2.0.30 패치 파일을 구해서 패치를 소스 트리에 적용하면 된 다.

$ cd /usr/src/inux
$ patch -p1 < patch-2.0.30

이는 전체 소스 트리를 복사할 필요가 없어, 느린 직렬 연결을 통하는 경우 더욱 유용하다. 커널 패치를 구하기 좋은 곳은(공식적이던 비공식적이던) http://www.linuxhq.com 웹 사이트이다².

커널 소스는 어떻게 배열되어 있는가

소스 트리의 시작인 /usr/src/linux에서 보면 여러개의 디렉토리가 있다.

arch arch 서브디렉토리는 모든 아키텍쳐에 종속적인 커널 코드를 포함하고 있다. 여기에는 서브디렉토리가 더 있는데, 각각 지원하는 아키텍쳐별로 있다. 예를 들어 i386, alpha같은 이름의 서브디렉토리가 존재한다.

include include 서브디렉토리는 커널 코드를 빌드하는데 필요한 모든 인클루드(include) 파 일들의 대부분을 가지고 있다. 여기에는 지원하는 아키텍쳐별로 하나씩 서브디렉토리가 있 다. /include/asm 서브디렉토리는 현재 아키텍쳐에 필요한 실제 디렉토리로 (예를 들어, include/asm-i386) 소프트 링크되어 있다. 아키텍쳐를 다른 것으로 바꾸려면 커널 makefile을 수정하고 리눅스 커널 환경설정 프로그램으로 돌아와야 한다.

init 이 디렉토리는 커널의 초기화 코드를 가지고 있으며, 커널이 어떻게 동작하는지 보기 시작하기에 좋은 곳이다.

mm 이 디렉토리는 모든 메모리 관리 코드를 가지고 있다. 아키텍쳐 종속적인 메모리 관리 코드는 arch/*/mm/ 아래에 있다. 예를 들어, arch/i386/mm/fault.c 같은 곳에 있다.

drivers 모든 시스템의 디바이스 드라이버는 이 디렉토리에 있다. 이들은 디바이스 드라이버 의 유형별로 좀더 세분화 되면. 예를 들어 블럭 디바이스 드라이버는 block에 있다.

ipc 이 디렉토리는 커널의 프로세스간 통신 코드를 가지고 있다.

modules 이는 단순히 빌드된 모듈을 저장하기 위한 디렉토리이다.

fs 모든 파일 시스템 코드를 가지고 있다. 파일 시스템별로 하나씩 디렉토리가 세분화된다. 예를 들어 vfat, ext2 같은 서브디렉토리가 있다.

kernel 메인 커널 코드가 들어 있다. 아키텍쳐 종속적인 커널 코드는 arch/*/kernel에 있다.

net 커널의 네트워킹 코드가 들어 있다.

lib 이 디렉토리는 커널의 라이브러리 코드를 가지고 있다. 아키텍쳐 종속적인 라이브러리 코드는 arch/*/lib/에 있다.

scripts 이 디렉토리는 커널을 설정하는데 사용되는 스크립트(예를 들어 awk나 tlk 스크립 트)를 가지고 있다.

어디서부터 보기 시작할 것이가

리눅스 커널처럼 방대하고 복합적인 프로그램은 들여다보기에 위압적일 수 있다. 이는 실로 된 커다란 공처럼 끝이 보이지 않는 것이기도 하다. 커널의 한 부분을 보다 보면 관련된 다 른 여러 파일들을 보게되고, 오래지 않아 무엇을 찾으려고 했는지 잊어버리게 된다. 다음 작 은 장들은 어떤 주제를 보려 할때 소스 트리의 어디를 보는게 좋은지 힌트를 제공할 것이다.

시스템 시작과 초기화

인텔 기반 시스템에서, 커널은 loadlin.exe나 LILO가 리눅스 커널을 메모리로 읽어들인 후 커널에 제어권을 넘겨줌으로써 시작한다. 이 부분에 대해서는 arch/i386/kernel/- head.S를 보기 바란다. head.S는 아키텍쳐 종속적인 셋업을 한 후 init/main.c에 있 는 main() 루틴으로 점프한다.

메모리 관리

이 코드는 대부분 mm에 있지만, 아키텍쳐 종속적인 코드는 arch/*/mm에 있다. 페이지 폴 트 처리 코드는 mm/memory.c에 있고, 메모리 매핑과 페이지 캐시 코드는 mm/filemap.c 에 있다. 버퍼 캐시는 mm/buffer.c에, 스왑 캐시는 mm/swap_state.c와 mm/- swapfile.c에 구현되어 있다.

커널

상대적으로 일반적인 코드는 kernel에 있고, 아키텍쳐 종속적인 코드는 arch/*/kernel 에 있다. 스케쥴러는 kernel/sched.c에 있고, fork 코드는 kernel/fork.c에 있다. 하반 부 핸들러 코드는 include/linux/interrupt.h에 있다. task_struct 자료구조는 include/linux/sched.h에서 찾을 수 있을 것이다.

PCI

PCI 유사 드라이버는 drivers/pci/pci.c에 있고, 시스템 범위의 정의들은 include/- linux/pci.h에 되어 있다. 각 아키텍쳐들은 특정 PCI BIOS 코드를 가지고 있는데, 알파의 PCI BIOS 코드는 arch/alpha/kernel/bios32.c에 있다.

프로세스간 통신

이것은 모두 ipc에 들어 있다. 모든 시스템 V IPC 오브젝트들은 ipc_perm 자료구조에 들 어 있고, include/linux/ipc.h에서 찾을 수 있다. 시스템 V 메시지들은 ipc/msg.c에, 공유 메모리는 ipc/shm.c에, 세마포어는 ipc/sem.c에 구현되어 있다. 파이프는 ipc/pipe.c에 구현되어 있다.

인터럽트 처리

커널의 인터럽트 처리 코드는 대부분 모두 마이크로프로세서 (때때로 플랫폼) 종속적이다. 인텔의 인터럽트 처리 코드는 arch/i386/kernel/irq.c에 있고, 정의는 include/asm- i386/irq.h에 되어 있다.

디바이스 드라이버

리눅스 커널 소스 코드의 대부분은 디바이스 드라이버에 있다. 모든 리눅스 디바이스 드라 이버 소스는 drivers에 있지만, 이들은 장치 유형에 따라 세분화 된다. /block 블럭 디바이스 드라이버. 예를 들어 IDE 디바이스 드라이버는 ide.c에 있다. 모든 장치가 어떻게 파일 시스템을 가질 수 있으며, 어떻게 초기화되는지 보고 싶다면 drivers/block/genhd.c에 있는 device_setup()을 보기 바란다. 이는 하드 디스크만 초기화하는 것이 아니라, 네트웍을 nfs 파일 시스템에 마운트하려고 한다면 네트웍도 초기 화한다. 블럭 장치에는 IDE와 SCSI 기반 장치가 포함된다.

/char ttys, 시리얼 포트나 마우스같은 문자 기반 장치들을 볼 수 있다.

/cdrom 리눅스의 모든 CDROM 코드가 들어 있다. 특별한 CDROM 장치(Soundblaster CDROM 같은)도 여기서 찾을 수 있다. IDE CDROM 드라이버는 drivers/block에 있는 ide-cd.c에 있고, SCSI CDROM 드라이버는 drivers/scsi에 있는 scsi.c에 있다는 점 에 주의하기 바란다.

/pci 여기에는 PCI 유사 드라이버의 소스가 있다. PCI 서브시스템이 어떻게 매핑되고 초기화 되는지 보기 좋은 곳이다. 알파 AXP PCI 확정 코드는 arch/alpha/kernel/bios32.c에 있고, 이는 볼만한 가치가 있다.

/scsi 모든 SCSI 코드와 함께 리눅스가 지원하는 모든 SCSI 장치들의 드라이버가 있는 곳이 다.

/net 네트웍 장치 디바이스 드라이버를 볼 수 있는 곳이다. DECChip 21040 PCI 이더넷 드라 이버는 tulip.c에 있다.

/sound 모든 사운드 카드 드라이버가 있는 곳이다.

파일 시스템

EXT2 파일 시스템 소스는 fs/ext2/ 디렉토리에 있고 자료구조는 include/linux/- ext2_fs.h, ext2_fs_i.h, ext2_fs_sb.h에 정의되어 있다. 가상 파일 시스템 자료구조 는 include/linux/fs.h에 정의되어 있고, 코드는 fs/*에 있다. 버퍼 캐시와 update 커널 데몬은 fs/buffer.c에 구현되어 있다.

네트웍

네트워킹 코드는 net에 있고, 인클루드(include) 파일들의 대부분은 include/net에 있다. BSD 소켓 코드는 net/socket.c에 있고, IP 버전 4 INET 소켓 코드는 inet/ipv4/- af_inet.c에 있다. 일반적인 프로토콜 지원 코드는 (sk_buff 처리 루틴도 포함하여) net/core/에, TCP/IP 네트워킹 코드는 net/ipv4/에 있다. 네트워크 디바이스 드라이버는 drivers/net에 있다.

모듈

커널 모듈 코드는 일부분은 커널에, 일부분은 modules 패키지에 있다. 커널 코드는 모두 kernel/modules.c에 있고, 자료구조와 커널 데몬 kerneld 메시지는 include/- linux/module.h와 include/linux/kerneld.h에 있다. ELF 오브젝트 파일의 구조는 include/linux/elf.h에서 볼 수 있다.

번역 : 이호, 이대현, 김진석, 심마로
정리 : 이호

media=”print” 를 지정해 주면 어렵지 않게 인쇄 시에 출력될 프레젠테이션에 스타일을 바꿀수 있습니다. print.css 경로를 제대로 잡아주시는것 아주 중요합니다.

display:none;

프린트 스타일시트 제작시에는 Law of Elimination, 즉 불필요한 정보 제거 작업부터 시작 하시는 것이 좋습니다. 불필요한 요소들을 먼저 살펴보시고 {display:none;} 에다가 하나씩 더해갑니다. 보편적으로 메뉴부분, 사이드바 부분, 인풋 박스, 광고 등이 해당되겠습니다. 일모리네를 예로 들자면 사이드바, 메뉴, 코멘트부분 알림 해더 등등을 지워버렸습니다.

배경과 폰트 지정

대충 지우신 후에 기본적인 배경과 폰트지정 으로 넘어갑니다. 폰트 사이즈는 프린트를 위한 pt (point) 단위로 잡으시고 9에서 12 사이로 잡아주시면 되겠습니다. 저는 9pt 로 잡았습니다. 그리고 배경은 transparent 이 default 이지만 혹시나 어딘가에 껴 들어가는것을 미리 방지하는 차원에서 transparent으로 잡아주면 좋겠죠. body의 배경을 흰색으로 잡아주면 마무리 되겠습니다. 또한 브라우저에게 해더 사이즈를 맡겨 놓으면 상당히 크고 낭비가 심하니 직접 h1, h2, h3 사이즈를 잡아주는 것도 좋은 방법입니다. 아시다시피 해더들은 기본적으로 굵게 bold 출력됩니다.

글을 글답게 세밀하게

위의 부분만 하셔도 어느정도 문서 분위기가 나겠지만 (ie6 포함) 약간만 더 손을 본다면 더할 나위 없는 프린트 지정이 될수 있습니다. 먼저 링크 부분을 손보겠습니다. 기본색인 파란색도 좋지만 흑백 프린트시에는 별 효과가 없으니 밑줄을 주어 링크를 표기할수 있습니다. 간단히 a {color: black; text-decoration: underline;} 을 주면 되겠습니다. 하지만 밑줄이 혼란스럽다면 밑줄 대신 링크뒤에 주소를 삽입하는 방법을 택하셔도 됩니다. 오래전에 Eric Meyer 가 나누었던 방법입니다.

브라우저가 지원만 한다면 (사파리가 아주 잘보이는 군요) #content 안에 있는 링크 뒤에 주소를 출력 하도록 하게 합니다. 하지만 #content 안의 글 제목에도 링크가 붙게되니 글 자체의 블록엘리먼트를 지정해 주어서 글 안의 링크에만 출력되도럭 하는 것이 좋은 방법이겠습니다. 일모리네는 .writing 부분이겠네요. 이러한 방법으로 링크를 지정해 주면 인쇄물이지만 웹주소를 찾아갈수 있는 장점이 있겠습니다.

링크에 스타일을 주었으니 문단에도 스타일을 지정해 보겠습니다. 문단 시작시에 들어짜기, 움푹 들어간 부분의 indentation 을 주어 문단 시작을 표현할수 있습니다. text-indent: 값; 의 형식을 사용하면 되겠네요. 또한 인쇄는 페이지라는 테두리가 있기에 문단이 페이지의 마지막 부분일때에 한줄만 출력되고 다음 페이지로 넘어가는 경우가 있을수 있습니다. 이 때에 orphans를 지정해 주면 orphans 에 지정된 값 데로 문단의 최소 출력이 지정됩니다.

마지막으로 전체적인 여백의 문제나 간격등을 조절해 주면 되겠습니다. content에 margin 값을 준다거나 문단간의 간격 조절등이 되겠네요.

일모리네 print.css 입니다.

body {font: 9pt/1.5 sans-serif;background: white; color: black;}

.left {float:left;}
.picL{float:left;}
.right {float:right;}
.border1 {border: 1px solid #000;}

a {color: black; text-decoration:none;}

h1 {font-size: 18pt;}
h2 {font-size: 15pt;}
h3 {font-size: 11pt;}
p {text-indent: 15pt; orphans: 3;}

#sidebar, #menu, #header_special, .permlink, .ttag, .ad, 
#commentinputs, #commentwrap h2, .comment {display:none;}

#content {width: auto;}

사람들은 갈 길이 멀면 끝이 없는 것처럼 생각하지.
길이 너무 멀어 도착하지 못할 거라 생각하는 거야.
하지만 그건 잘못된 생각이지.
그럼 마음이 급해져 서두르게 되고,
암만 달려도 길은 여전히 멀다는 정말 뿐이거든.

먼 길을 단번에 강 생각을 하면 안 돼.
어떻게 하냐고?
그럼 한검을씩 차근차근 간다고 생각을 해봐.
천천히 숨을 쉬며,
자신의 걸음걸이를 즐기는 거야.
그게 중요해.
그게 먼 길을 가는 가장 쉬운 방법이야.

한걸음씩 천천히 가다 보면
숨도 가쁘지 않고,
먼 길을 왔다는 사실조차 모르게 되지.
그게 중요한 거야.

-영화 <모모> 중에서-