Linux 커널 드라이버 모형: 협업의 장점 - in Beautiful code

Linux 커널 드라이버 모형: 협업의 장점

  그레그 크로아 - 하트먼

리눅스 커널 드라이버 모형은 운영체제가 관리하는 모든 종류의 장치를 포괄하는 하나의 시스템 전역적 트리를 구축하기 위한것이다.

지난 수년 동안, 이를 위해 핵심 자료구조와 코드는 몇안되는 장치들을 다루는 하나의 아주 단순한 시스템으로 시작해서 현실 세계에서 처리할 필요가 있는 모든 종류의 장치를 제어하는 고도로 규모가변적인 시스템으로 발전해 왔다.

Linux 커널이 발전함에 따라 처리해야 하는 주변 장치들의 종류도 점점 더 늘어나게 되었는데, 그 과정에서 커널의 핵심부(Core)는 그렇게 다양한 장치 형식들을 좀 더 쉽게 관리할 수 있는 방식들을 받아들이며 진화해 왔다.

거의 모든 장치는 두 개의 구별되는 부분으로 구성된다. 하나는 운영체제와 장치의 연동 방식(PCI버스,SCSI버스,ISA버스,USB 버스 등을 통한)을 정의하는 물리적 부분이고 또 하나는 사용자가 장치를 적절히 사용할 수 있도록 운영체제가 장치를 사용자에게 제시하는 방법을 정의하는 가상의 부분(키보드, 마우스, 비디오,사운드 등)이다.

2.4 커널 릴리즈들에서는 장치의 물리적인 부분을 코드의 버스 관련 부분이 제어했다. 이 버스 코드는 다양한 과제들을 담당했는데, 각각의 개별 버스 코드는 다른 어떤 버스 코드와도 상호작용하지 않았다.

2001년에 모컬(Pat Mochel)은 Linux 커널의 전완 관리 문제를 해결하던 와중에 개별장치를 적절히 끄거나 켜기 위해서는 커널이 서로 다른 장치들 사이의 연결 관계를 알고 있어야 한다는 점을 깨닫게 되었다. 예를 들어 USB 컨트롤러를 끄기 위해서는 PCI 컨트롤러를 끄기전에 먼저 USB 디스크 드라이브를 꺼야 한다. 그래야 해당 장치에 자료를 적절히 저장할 수 있다. 이러한 문제를 해결하려면 시스템의 모든 장치의 연결관계와 연결 순서를 알 수 있는 하나의 트리가 있어야 한다.

다른 운영체제들은 장치의 이름 식별을 처리하는 작은 데이터베이스를 커널안에 두거나 한장치의 모든 가능한 고유 특성을 장치에 직접 접근하는데 사용할 수 있는 deffs 형식의 파일시스템에 익스포트함으로써 이런 문제를 해결했다. 그러나  Linux의 경우 커널에 데이터베이스를 두는 방식을 받아들일 수 없었다. 또한 Linux 의 devfs 파일시스템 구현에는 잘 알려진, 그리고 교정이 불가능한 race condition(경쟁조건)들이 여럿 존재하는 탓에, 거의 모든 Linux 배포판 들은 그 파일 시스템을 신뢰하지 않았다. devfs 해법은 또한 사용자에게 특정한 명명(naming)정책을 강요했다. 이를 장점으로 받아들인 사람들도 있었지만, 그 정책은 공표된 Linux 장치 명명 표준과 맞지 않을 뿐만 아니라 사용자가 자신이 원하는 다른 명명 정책을 사용하지 못하게 된다는 단점을 가지고 있다.

모컬과 나(그레그 크로아)는 우리의 문제가 Linux 커널 안에 있는 하나의 통합된 드라이버 및 장치 모형을 통해서 해결될 수 있음을 깨닫게 되었다. 그러한 통합 모형이 어떤 새로운 아이디어였던 것은 아니다. 그와 같은 통합 모형을 채용한 운영체제들은 과거에도 존재했다. 단지 ,Linux에서도 그것을 사용할 때가 되었던 것일 뿐이다. 

우리에게 필요한 것은 모든 장치의 트리를 생성하는데 사용할 수 있을 뿐만아니라 커널 외부의 사용자(userspace)프로그램도 임의의 장치에 대한 영속적인 이름을 사용자가 원하는 방식으로 처리할 수 있게 만드는 통합 모형이었다.

-- 소박한 시작

우리는 커널의 모든 장치에 대해 하나의 "기반" 클래스로 사용할 device라는 간단한 구조체를 만드는 일부터 시작했다.

초기에는 이 구조체는 다음과 같은 모습이었다.

struct device{

   struct list_head node;   /*sibling node */

   struct list_head children;

   struct device * parent;

   char name[DEVICE_NAME_SIZE];   /*서술적인 ASCII 문자열*/

   char bus_id[BUS_ID_SIZE];    /*부모 버스에서의 위치*/

   spinlock_t lock;                        /*서로다른 두 계층이 동시에 접근하지 못하도록 만드는 락*/

   atomic_t refcount;                     /* 장치가 적절한 시간동안 지속되게 만들기 위한 참조 회수(참조되고 있는 count)*/

   struct driver_dir_entry * dir; 

   struct device_driver * driver;       /*이 장치를 할당한 드라이버*/

   void * driver_data;                     /* 이장치의 전용 자료*/

   void * platform_data;                 /* 플렛폼 관련 자료(ex ACPI ,장치 BIOS 자료)*/

   u32 current_state;                      /*현재 작동상태. ASCI의 용어로 말하자면, 이것은 D0-D3 

                                                      D0는 완전히 켜졌음을 뜨하며, D3은 완전히 꺼졌음을 뜻한다.*/

   unsigned char * saved_state;    /*저장된 장치 상태*/

};

이 구조체를 생성해서 커널 드라이버 핵심부에 등록할 때마다 해당 장치와 그에 담긴 임의의 서로 다른 특성들을 대표하는 하나의 항목이 가상 파일 시스템에 만들어진다. 이를 통해서 시스템의 모든 장치가 사용자공간에 노출되며, 사용자 공간 프로그램은 이 가상 파일 시스템을 통해서 원하는 장치를 연결한다. 지금은 이러한 가상 파일시스템을 sysfs라고 부르는데, Linux가 깔린 컴퓨터의 /sys/devices 디렉터리에서 볼수 있다. 다음은 몇 가지 PCI와 USB장치들에 해당하는 부분이다.

/*원래는 여기에 linux의 device 내용들이 표시되어야 하는데. 타이핑 하기엔 너무 복잡해서 생략!!*/

struct usb_interface {

 struct usb_interface_descriptor * altsetting;

  int act_altsetting;                  /*활성화된 대체 설정*/

  int act_altsetting;                  /*대체 설정들의 개수*/

  int act_altsetting;                  /*할당된 메모리 총량*/

  struct usb_driver * driver;      /*드라이버*/

  struct device dev;                /*장치정보 관련 인터페이스*/

};

드라이버 핵심부는 struct device에 대한 포인터들을 주고받으면서 그 구조체에 있는 기본적인 ,즉 모든 장치에 공통인 필드들에 대한 작업을 수행한다.

포인터가 다양한 기능을 위한 버스 관련 코드로 넘겨질때에는 그것을 담고 있는 실제 구조체 형식으로 변환해야 한다. 이러한 변환을 처리하기 위해, 버스 관련 코드는 메모리 안에서의 포인터의 위치에 기초해서 포인터를 다시 원래의 구조체로 형변환 한다. 이를 담당하는 것이 다음의 메크로함수이다.

#define container_of(ptr,type,member) ({ \ 

          const typeof( (type*)0)->number)*__mptr = (ptr);\

          (type *)((char*)__mptr-offsetof(type,member) );})

예로 원래의 구조체의 struct device 멤버에 대한 포인터를 앞에 나온 struct usb_interface ㅍ포인터로 변환하는 코드를 보자.

int probe(struct device * d){

struct usb_interface * intf;

intf = container_of(d,strcut usb_interface , dev);

:

:

}

container_of 메크로와 같은 간단한 방법 덕분에 Linux 커널은 보통의 C구조체들을 아주 강력한 방식으로 상속하고 조작할 수 있게 되었다. 물론 그런 강력함은 개발자가 이들의 작동 방식을 제대로 알고 사용한다는 가정하에서의 이야기 이다.

애초에 struct device로 전달된 포인터가 실제로 struct usb_interface 형식인지를 실행시점에서 점검하지 않는다는 데에 의문을 표하는 독자도 있을 것이다.

전통적으로 , 이런 종류의 포인터 조작을 수행하는 시스템들은 대부분 기반 구조체에 조작 중인 포인터의 형식을 정의하는 하나의 필드를 두고 그것을 이용해서 프로그래머가 형식을 잘못 지정하는 실수를 검출한다. 또한 그러한 필드는 실행 시점에서 포인터의 형식을 동적으로 결정하고 그에 따라다른 일을 수행하는 코드를 작성할 때에도 요긴하게 쓰인다.

그러나 Linux 커널 개발자들은 그런 종류의 점검이나 형식 정의를 빼기로 결정했다. 그런 점검들의 경우 개발 초기의 기본적인 프로그래밍 실수를 잡아내는데 도움이 되기도 하지만, 나중에는 쉽게 잡아내기가 힘든 훨씬 더 미묘한 문제들로 이어질 수 있는 어떤 교묘한 편법들을 가능하게 만드는 수단으로도 악용 될 수도 있기 때문이다.

실행시점 형식 점검이 없기 때문에, 이런 포인터들을 다루는 개발자들은 자신이 다루고 넘겨주는 포인터의 형식을 반드시 명확하게 알고 있어야 한다. 물론 가끔은 자신이 보고있는 struct device의 구체적인 형식을 알아낼 수 있는 어떤 수단이 있으면 좋겠다는 생각도 들겠지만, 그런 생각은 문제를 적절히 디버깅하고 나면 사라진다.

형식 점검의 부재가 코드의 아름다움에 기여할 수 있을까? 이부분을 오년 이상 다뤄 온 입장에서 이야기하자먄, 답은"그렇다"이다.

이런 부재는 커널 내에서 종종 나타나는 손쉬운 편법을 방지하며, 모두가 자신의 로직을 아주 정확하게 짜도록 강제한다. 개발자들이 형식 점검에 의존하지 않도록 강제함으로써 버그를 미연에 방지할 수 있는 것이다.

여기서 나는 커널의 이 부분을 다루는 개발자들(공통 버스들을 위한 하위 시스템을 코딩하는 사람들)이 비교적 그 수가 적고 또 상당한 수준의 전문 지식 및 경험을 갖추었을 것으로 기대할 수 있다는 점을 지적해두고 싶다. 형식 점검이라는 안전장치를 두지 않는 것도 바로 이러한 이유에서이다.

기반 struct device구조체를 이런식으로 상속하는 방법 덕분에, 2.5 커널 개발 공정에서 우리는 서로 다른 모든 드라이버 하위 시스템들을 하나로 통합 할 수 있었다. 드라이버 시스템들은 이제 모두 공통의 핵심코드를 공유하며, 이에 의해 커널은 사용자에게 장치들이 어떻게 연결되어있는지를 제시할 수 있게 되었다.

또한 작은 사용자 공간 프로그램에서 영속적인 장치명명을 수행하는 udev 같은도구나 장치들의 트리를 훑으면서 장치들을 적절한 순서로 끄는 전원관리 모듈을 작성하는 것도 가능해 졌다.

-- 더욱 작은 조각들로 줄이기

초기의 드라이버 핵심부를 다시 만드는 도중에, 또 다른 커널 개발자인 바이로(Al Viro) 는 가상 파일시스템 계층에서의 객체 참조 횟수 집계와 관련된 몇 가지 문제점들을 고치고 있었다.

C언어로 작성된 다중 스레드 프로그램에서 구조체들에 생기는 주된 문제는, 한 구조체가 사용하는 메모리를 안전하게 해제 할 수 있는 시점을 결정하는 것이 아주 어렵다는 것이다. Linu 커널은 부주의한 사용자들 뿐만 아니라 동시에 실행되는 많은 수의 프로세서들도 적절히 처리해야 하는 하나의 대규모 다중 스레드 프로그램이다. 이 때문에 둘 이상의 스레드들이 사용하는 임의의 구조체에 대한 참조 횟수 관리가 필수적이다.

struct device 구조체도 그런 참조 횟수 관리 대상 중 하나였다. 이구조체에는 구조체를 해제해도 안전한지를 결정하는 데 쓰이는 다음과 같은 필드가 있다.

atomic_t refcount;

구조체가 처음 초기화 될 때 이 필드는 1로 설정된다. 이 구조체를 사용하고자 하는 코드는 우선 get_device 함수를 호출해서 참조 횟수를 증가해야 한다. 그 함수는 기존 참조 횟수가 유효한지 점검한 후 그것을 하나 증가한다.

static inline void get_device(struct device * dev)

{

BUG_ON(!atomic_read(&dev->refcount));

atomic_inc(&dev->refcount);

}

비슷하게 , 한 스레드가 구조체를 다시 사용했다면 put_device 함수를 호출해서 해당 참조 횟수를 하나 감소한다. 이 함수는 좀 더 복잡하다.

void put_device(struct device * dev)

{

if ( !atomic_dec_and_lock(&dev->refcount,&device_lock))

return;

:

:

/*

드라이버에게 구조체를 해제하게 한다.

우리가 장치를 할당 하지 않았을 가능성이 크므로,

지금이 드라이버가 장치를 해제할 기회이다...

*/

if (dev->driver && dev->driver->remove)

dev->driver->remove(dev,REMOVE_FREE_RESOURCES);

}

이 함수는 해당 구조체의 참조 횟수를 감소한다. 만일 그것이 0이면 구조체가 더 이상 쓰이지 않는 것이므로 드라이버에게 해당 구조체를 정리하게 한다( 그런용도로 시스템이 설정해 둔 함수를 호출해서).

바이로는 struct device 구조체의 통합과 서로 다른 모든 장치들을 보여주는 가상 파일시스템, 그것들이 서로 연결되는 방식, 그리고 자동적인 참조 집계 방싯을 맘에 들어 했다. 문제는 그의 가상 파일시스템 핵심부가 "장치"를 다루는 것이 아니며 이 객체들에 부착할 수 있는 "드라이버"도 없다는 데 있었다. 그래서 그는 코드를 조금 리팩토링해서 좀 더 단순하게 만들기로 결정했다.

바이로는 모컬을 설득해서 struct kobject라는 것을 만들게 했는데, 이 구조체는 struct device 구조체의 기본 속성들을 소유하되 더 작았고, 또 "드라이버"와 "장치" 관계는 가지지 않았다. 이 구조체의 필드들은 다음과 같다.

struct kobject {

char                          name[KOBJ_NAME_LEN];

atomic_t                    refcount;

struct list_head           entry;

struct kobject              *parent;

struct subsystem        *subsys;

struct dentry               *dentry;

};

이 구조체는 일종의 빈(empty)객체로, 참조 집계 및 객체들의 계통구조로의 삽입을 위한 아주 기본적인 기능만을 가지고 있다.

struct device 구조체는 struct kobject라는 이 더 작은 "기반" 구조체를 자신의 필드로 둠으로써 이 기반 구조체의 모든 기능성을 상속한다.

struct device {

struct list_head g_list;

struct list_head node;

struct list_head bus_list;

struct list_head driver_list;

struct list_head children;

struct list_head intf_list;

struct device *parent;

struct kobject kobj;

char bus_id[BUS_ID_SIZE];

:

:

};

kobject 에서 struct device로의 형변환에는 다음과 같은 매크로가 사용된다. 앞에서 나왔던 container_of 매크로를 사용하는 것일 뿐이다.

#define to_dev(obj)  container_of(obj,struct device,kobj)

이러한 개발 과정에서, 다른 여러 사람들은 동일한 시스템 이미지에서 더욱 많은 프로세서들이 실행될 수 있도록 규모가변성을 보장하기 위해 Linux 커널의 안정성을 개선하는 작업을 진행했다. 이 때문에, 여러 개발자들이 자신의 메모리 사용을 적절히 처리하기 위해 자신의 구조체에 참조 횟수를 추가하게 되었고, 각 개발자들은 구조체의 초기화, 참조 횟수 증가, 감소, 마무리를 위한 코드를 복제해야 했다.

그래서 struct kobject 의 간단한 기능을 뽑아 개별적인 구조체를 만들기로 했는데, 그 결과가 바로 struct kref 구조체이다.

struct kref 

{

atomic_t refcount;

};

struct kref는 단 세개의 단순 함수만을 가진다. kref_init는 참조 횟수를 초기화하고, kref_get은 참조 횟수를 증가하며, kref_put 은 참조 횟수를 감소한다. 처음 두 함수는 아주 간단하다. 살펴볼만한 것은 마지막 함수 뿐이다.

int kref_put(struct kref * kref, void (*release)(struct kref * kref))

{

WARN_ON(release == NULL);

WARN_ON(release == (void (*)(struct kref *))kfree);

if(atomic_dec_and_test(&kref->refcount)){

release(kref);

return 1;

}

return 0;

}

kref_put  함수는 두 개의 매개변수를 받는다. 하나는 참조 횟수를 감소할 struct kref를 가리키는 포인터이고 또 하나는 객체가 더이상 참조되지 않을 경우에 호출될 해제 함수를 가리키는 포인터이다.

함수의 처음 두 줄은 struct kref가 커널에 처음 추가될 당시에는 없었는데, 의도적으로 참조 횟수 관리를 피하려 드는 프로그래머들 때문에 추가한 것이다. 그들은 해제 함수에 대한 포인터를 아예 제공하지 않거나, 그에 대한 커널이 불평을 하면 기본 kfree 함수에 대한 포인터를 제공함으로써 참조 횟수 관리를 피하려 했다.

인수들이 이 두 점검들을 통과했다면 kref_put 함수는 참조 횟수를 원자적으로 감소한다. 그리고 이것이 객체에 대한 마지막 참조였다면, 주어진 해제 함수를 호출하고 1을 돌려준다. 마지막 참조가 아니었다면 0을 돌려준다ㅏ. 이 반환값은 호출자가 객체를 마지막으로 참조했던 것이 었는지의 여부를 알려줄 뿐, 객체가 여전히 메모리 안에 존재하는지를 알려주지는 않는다(호출이 반환된 이후에 다른 누군가가 객체를 해제할 수도 있으므로, 이 반환값으로 객체의 존재 여부를 보장할 수 없다).

struct kref가 도입되면서 struct kobject는 kref를 사용하도록 바뀌었다.

struct kobject{

char              name[KOBJ_NAME_LEN];

struct kref      kref;

:

:

}

이렇게 한 구조체 안에 다른 구조체를 집어넣는 방식을 적용한 결과, 원래의 struct usb_interface는 이제 하나의 struct device를 담게 되었고, 그것은 다시 struct kobject를 그것은 다시 struct kref를 담게 되었다. 

-- 장치 수천개로의 규모 확장

Linux는 휴대 전화, 무선조종 헬리콥터, 데스크톱, 서버는 물론 세계 최대 슈퍼 컴퓨터들의 73퍼센트에 이르기까지 거의 모든 플랫폼에서 실행된다. 그런 만큼 드라이버 모형의 규모가변성은 매우 중요한 사안이었으며, 항상 우리의 주된 관심사였다. 개발이 진행됨에 따라, 장치들을 담는데 쓰이는 구조체들, 즉 struct kobject와 struct device 가 비교적 작다는 점이 여러모로 도움이 되었다.

대부분의 시스템들에서 시스템에 연결된 장치 개수는 그 시스템의 크기와 정비례한다.

작은 임베디드 시스템의 경우에는 시스템에 연결된( 그리고 트리에 존재하는) 장치들이 하나에서 열 개 정도이다. 좀 더 큰 " 전사(enterprise)"시스템에는 그보다 훨씬 많은 장치들이 연결되지만, 그런 시스템들은 메모리도 넉넉하기 때문에,늘어난 장치들의 메모리 사용량은 여전히 커널의 전반적인 메모리 사용량의 아주 적은 부분을 차지한다.

그러나 "전사적" 시스템들 중에는 이런 느긋한 규모가변 모형이 완전히 깨지는 경우가 하나 있다. 바로 s390 메인프레임 컴퓨터이다. 이 컴퓨터의 경우 Linux가 하나의 가상 파티션에서 실행된다. 한 컴퓨터에서 최대 1,024개의 Linux 인스턴스들이 동시에 실행될 수 있고, 각 인스턴스에는 엄청나게 많은 개수의 서로 다른 저장 장치들이 연결된다. 전체적으로는 시스템의 메모리가 넉넉하지만 각 가상 파티션에는 그 메모리의 아주 작은 부분만 배정된다. 각 가상 파티션에 할당되는 메모리는 RAM 수백 메가 정도이나, 그래도 각 파티션은 서로 다른 저장 장치 모두(일반적으로 20,000개 정도)를 인식해야 한다.

이러한 시스템들에서는 장치 트리가 메모리의 상당 부분을 차지하게 되고, 그런 메모리는 결코 사용자 프로세스들에게 주어지지 않는다. 드라이버 모형의 살을 좀 빼야 할 때가 된 셈이었는데, 이 문제의 해결에 IBM의 똑똑한 커널 개발자 여러 명이 달라붙었다.

그 와중에 개발자들은 다소 놀라운 사실을 발견하게 되었다. 주된 struct device 구조체는 단 160 바이트 정도였고(32bit 프로세서의 경우), 따라서 시스템에 장치가 20,000개라고 해도 그 구조체들이 차지하는 메모리는 3,4MB밖에 되지 않았다. 이 정도는 충분히 감당할 수있는 수준이다. 실제로 메모리를 크게 잡아먹는 것은 앞에서 언급한, 모든 장치를 사용자공간에 노출하기 위한 RAM 기반 파일시스템 sysfs였다. 장치들 각각에 대해 sysfs는 하나의 struct inode와 하나의 struct dentry를 생성한다. 이들은 모두 상당히 뚱뚱한 구조체들로, struct inode는 약 256바이트 struct dentry는 약 140바이트이다.

각 struct device마다 적어도 하나의 struct dentry와 struct inode가 생성되었다. 전반적으로 이런 파일시스템 구조체들의 수많은 복사본들이 생성된다.

한 예로, 하나의 블록 장치는 약 10개의 서로다른 가상 파일들을 생성하며, 따라서 160바이트짜리 구조체 하나가 무려 4KB를 자치할 수도 있는 것이다. 장치가 20,000개인 시스템의 경우 가상 파일시스템이 약 80MB의 공간을 차지했다. 이 메모리는 커널이 소비하는 것이므로 어떠한 사용자 프로그램도 사용할 수 없었다. sysfs에 저장된 정보를 전혀 요구하지 않는 프로그램도 많다는 점을 감안한다면 이는 심각한 낭비였다.

이에 대한 해결책은 struct inode와 struct dentry 구조체들을 커널의 캐시에 넣되, 파일시스템 접근이 일어날 때마다 즉석에서 그것들을 생성하도록 sysfs의 코드를 재작성하는 것이었다. 구체적으로는, 장치가 처음 생성될 때 모든 것을 미리 할당해 두는 대신, 사용자가 트리를운행함에 따라 동적으로 디렉터리와 파일을 생성하는 방식이다. 이 구조체들은 커널의 주 캐시메모리 요구를 만족시킬 수 없으면 시스템은 캐시를 비워서 메모리를 확보하고 확보된 메모리를 애초에 메모리를 요구한 곳에 제공할 수 있다. 모든 변화는 sysfs의 백엔드 코드에서 일어난것으로, 주 struct device 구조체는 전혀 변하지 않았다.

-- 느슨하게 결합된 작은 객체들

Linux 드라이버 모형은 C언어를 이용해서 각자 한 가지 일에 특화된 여러개의 작은 객체들을 생성함으로써 고도의 객체지향적 코드 모형을 만드는 예를 보여준다. 이 객체들은 다른 객체들에 내장될 수 있으며,이를 통해서 아주 강력하고 유연한 객체 트리를 만들 수 있다. 이 객체들의 실제 사용량에 근거할때, 이들의 메모리 사용량은 최소한도이다. 이 덕분에, 동일한 코드 기반이 아주 작은 임베디드 시스템에서부터 세계 최대의 슈퍼컴퓨터들에 이르기까지 다양한 규모의 플랫폼에서 실행될 수 있을 정도로 Linux커널이 유연해 졌다.

이 모형의 개발은 또한 Linux 커널 개발이 진행되는 방식의 아주 흥미롭고도 강력한 두가지 측면을 보여준다.

우선, 공정이 아주 반복적(iterative)이다. 커널의 요구사항이 변함에 따라, 그리고 그 커널을 기반으로 작동하는 시스템의 요구사항이 변함에 따라, 개발자들은 모형에 좀 더 효율적으로 만들어야 하는 부분을 식별하고 추상화하는 방법을 발견할 수 있었다. 이는 변화하는 환경에서 시스템이 살아남는데 필요한 기본적인 진화적 요구에 대한 응답이었다.

두번째로 , 장치 처리의 역사는 그 공정이 극도로 협동적임을 보여준다. 서로 다른 개발자들이 커널의 여러 측면을 개선하고 확장하기 위한 다양한 아이디어를 제시한다. 그 외의 사람들은 소스 코드를 통해서 그 개발자들의 의도를 그들이 서술한 바 그대로 인식할 수 있으며, 원래의 개발자들이 결코 고려하지 않았던 방식으로 코드를 변화시키는 데 도움을 주게 된다. 이러한 협동작업의 결과로, 개발자가 따로 일하는 경우에는 결코 발견할 수 없었을 하나의 공통된 해결책을 얻어냄으로써 서로 다른 여러 개발자들의 목표가 달성된다.

커널 드라이버 모형 개발의 이러한 두 가지 특성은 Linux가 지금까지 만들어진 운영체제들 중 가장 유연하고 강력한 운영체제로 발전하는 데 도움을 주었다. 이런 특성들이 유지되는 한, Linux는 여전히 그러한 운영체제의 자리를 차지하게 될 것이다.

----이 글을 읽고 나서

독후감(?) 같은 느낌으로 마무리를 하게 되는 군요.

처음 책의 내용을 이렇게 글로 옮기게 된것은, 그냥 훓어보면서 도대체 이야기하고자 하는 바가 잘 안와닿아서,

차분히 읽을겸 옮겨적게 되었습니다..

우선 내가 느낀점은 이글은 완성된 드라이버 모델의 장점에 중심을 두기 보다는,

개발자들이 협업하면서 드라이버 모델이 발전해가는 과정에 중심을 두고 있다는 것이 개발자로서 와 닫는 부분이었습니다.

거의 모든 책들이 사용자나 개발 결과물에 대한 내용을 주로 다룬 것에 반해 개발자의 노력으로 개선되어가는 플랫폼을 보여주었으며, 뭐 크게 쇼킹하다고 생각되는 기술적인 내용은 아니지만, 현업에서 소소한것 하나하나들을 좀 살펴보고 개선의 여지가 있는 것들을 찾아보려는 노력을 게을리 하면 안되겟다는 생각을 다지게 되는 군요.

학생때 즐기면서 코딩을 시작했던 개발자 분들 !!! 

그래도 다른 일 하는 것 보다는 즐겁잖아요.!! 즐기면서 합시다.!!!