이 절의 내용을 이해하지 못하겠다면 다음 절 2.2절 을 보라.
아주 간략히 말한다면, PnP 는 소프트웨어(디바이스 드라이버들)에게 어디에서 모뎀, 네트워크 카드, 사운드 카드등의 각종 하드웨어(디바이스)를 찾아야 하는지를 자동으로 알려주는 것이다(역주: PnP 를 쓰지 않는다면 사용자가 일일이 지정해 주어야만 한다). PnP 의 임무는 물리적 장치(디바이스)와 그를 조작하는 소프트웨어(디바이스 드라이버)를 서로 일치시키고, 각 디바이스와 그 드라이버 사이에 통신채널들을 만드는 것이다. 이를 실현하기 위해서 PnP는 다음의 "버스리소스(bus-resources)" 라는 것을 드라이버와 하드웨어의 양쪽에 할당한다: I/O 어드레스, IRQ, DMA 채널(ISA 버스의 경우만 해당), 메모리 영역. 이 4 가지를 일차적 리소스라고 부르기도 한다. 이 4 개의 버스리소스들이 뭔지 잘 모르겠다면 뒤에 나올 I/O 어드레스, IRQ, DMA 채널, 메모리 영역의 절을 읽어보라. 또 이 버스리소스들 중 3 가지에 관한 Linux Gazette 의 기사가 Introduction to IRQs, DMAs and Base Addresses 에 있다. 일단 이 버스리소스들이 할당되면 (그리고 올바른 드라이버가 설치되면), /dev 디렉토리에 있는 디바이스용 "파일"들을 사용할 수 있게 된다.
이렇게 PnP 가 버스리소스들을 할당하는 것을 "설정(configuring)" 한다라고 말하기도 하지만, 시실 이 PnP 설정이라는 것은 저수준 설정에 해당할 뿐이다. /etc 디렉토리 밑에는 많은 설정 화일들이 있다. 그 내용들의 대부분은 PnP 설정이 아니다. 하드웨어 디바이스들을 설정하는 작업의 상당부분은 PnP 와는 무관하다. PnP 설정은 전체 설정작업의 일부일 뿐인 것이다. 예를 들어, "초기화 문자열(init string)"을 보내 모뎀을 초기화시키거나 모뎀 속도를 설정하는 작업은 설정작업이긴 해도 PnP 설정작업은 아닌 것이다. 따라서, 앞으로 PnP 문제를 논할 때의 "설정(configure)" 이라는 용어는 어떤 특정한 종류의 설정작업만을 뜻하기로 한다. 다른 문서(예를 들면 MS 윈도우즈용의 문서등)에서는 버스 리소스를 "리소스(resources)" 라고 말하기도 하지만, 이 문서에서는 다른 종류의 많은 리소스들과 구별하기 위해서 "버스 리소스" 라는 용어를 사용하기로 한다.
컴퓨터는 계산을 담당하는 CPU(프로세서)와 프로그램 및 데이터를 저장하는 램 메모리(액세스속도가 빠르다)로 구성되어 있다. 여기에다 각종 디스크 드라이브들과 비디오 카드, 키보드, 네트웍 카드, 모뎀 카드, 사운드 카드, USB 버스, 시리얼 포트, 패러렐 포트 등등이 있고, 또 전력을 공급하는 전원부, 디바이스를 CPU 에 접속하기 위한 마더보드상의 각종 버스들, 그리고 이 모두를 담는 케이스가 있다.
옛날에는 대부분의 디바이스들은 각각 회로기판형(PCB, Printed Circuit Board) 카드형태로 제작되어 메인보드의 슬롯에 꽂히도록 되었었다. 그러던 것이 최근에는 많은 "디바이스" 들이 회로기판형태뿐 아니라 작은 반도체 칩 형태로도 집적되어 "마더보드" 상에 아예 영구적으로 실장되기도 한다. 또한 마더보드에 꽂는 하나의 카드위에 여러개의 디바이스가 탑재되는 경우도 있다. 메모리 칩들 역시 때로는 디바이스로 취급할 수도 있지만, 이 경우는 본 HOWTO 의 PnP 의 의미에는 해당하지 않는다.
컴퓨터 시스템이 제대로 동작하려면 각각의 디바이스는 해당 "디바이스 드라이버" 의 제어하에 있어야만 한다. 디바이스 드라이버는 운영체제의 일부인 소프트웨어로서 (대개는 모듈로서 로드된다), CPU 상에서 실행된다. 디바이스 드라이버들은 /dev 디렉토리에 있는 "특수 파일들"에 연관되어져 있는데, 이 파일들은 사실은 파일이 아니다. 이 파일들은 hda1(하드디스크 a 의 첫번째 파티션), ttyS0(첫번째 시리얼 포트), eth1(두번째의 이더넷 카드) 등의 이름을 가지고있다. 좀더 복잡하게는, 가령 eth1 용 디바이스 드라이버는 당신이 가진 이더넷 카드의 종류에 맞는것으로 선택해야 한다. 즉, 다짜고짜 아무 이더넷 드라이버에게나 eth1 을 지정해 주어서는 안되며, 반드시 당신이 설치한 이더넷 카드 종류에서 동작하는 특정 드라이버에게 eth1 을 지정해줘야 한다. 커널 모듈을 사용할 경우, 이러한 지정내용의 일부는 /etc/modules.conf 내의 alias 부분에 적히게 되며 그외 나머지 내용은 커널 내부의 테이블에 내재될 수도 있다.
어떤 디바이스를 제어하기 위해서는, 해당 디바이스 드라이버가 CPU 를 이용해 그 디바이스에 명령 및 데이터를 보내거나 디바이스로부터 정보를 읽어내야 한다. 이런 일을 하려면, 각 디바이스 드라이버들은 자신이 제어하는 디바이스의 어드레스를 알아야만 한다. 결국 그러한 어드레스를 안다는 것은 바로 디바이스와의 통신 채널을 설정한다는 것과 같은 의미인 것이다. 이 물리적인 "채널"은 실제로는 PC 내부의 데이터 버스로서, 디바이스뿐 아니라 다른 거의 모든 장치들에게도 공유되고 있다.
실제의 통신 채널은 위의 설명보다 조금 더 복잡하다. "어드레스" 란 실제로는 연속된 어드레스들로 이루어진 특정한 어드레스 범위를 뜻하는 것으로서 종종 "어드레스"란 말 대신 "어드레스 영역"이라고 말하기도 한다. 심지어는 한개의 단일 디바이스가 두개 이상의 어드레스 범위를 가질수도 있다(서로 중첩되지만 않으면 된다). 또한, 위와 반대방향의 채널에 해당하는 것으로 인터럽트가 있는데, 이를 통해서 이번에는 디바이스가 해당 디바이스 드라이버쪽으로 긴급 "구조요청" 을 보낼수 있다.
PC 에는 3 개의 어드레스 공간이 있다 : I/O , 메인 메모리(IO 메모리), 설정 어드레스(구형 ISA 버스는 이 "설정" 어드레스 공간이 없다). 이들 3 종류의 어드레스는 PC 내부의 동일 버스를 공유하고 있다. 어떤 어드레스가 I/O, 메인 메모리(2.5절), 설정 어드레스 셋 증의 어디에 속하는 것인지는 그 판별용으로 PC 의 버스상에 배선된 특정한 라인들의 전압으로 결정된다. 자세한 것은 9.2절 절을 참조하라. 이 세가지 어드레스 공간중 다음 두 가지만이 디바이스의 I/O 용도로 사용된다: I/O 와 메인 메모리.
디바이스들은 원래 I/O 어드레스 공간에 위치했었으나, 오늘날에는 메인 메모리내의 공간을 사용할 수도 있다. I/O 어드레스는 때로는 그냥 "I/O", "IO", "i/o", "io" 라고 부르기도 한다. 또 "I/O포트" 나 "I/O 영역" 이라 부르기도 한다. 이 "IO 포트" 와 메인 메모리에 위치하는 "IO 메모리" 를 혼동해서는 안된다. I/O 어드레스(또는 인터럽트같은 다른 버스 리소스 자원들)를 할당하려면 다음 두 단계를 거쳐야한다.
I/O 어드레스나 그밖의 내용을 카드상의 레지스터에 셋팅한다.
이 I/O 어드레스나 그밖의 내용을 디바이스 드라이버도 알게 한다.
위의 두 단계는 당신이 거리에서 어떤 이의 집의 번지수를 찾아내는 과정과 비슷하다. 먼저, 그 사람은 대문앞에 자기집의 번지수를 붙여놓아 외부에서 찾을수 있게 하여야 하고, 그러면 이를 통해 당신은 그 집 번지수를 얻어내 종이에 기록하면 된다. 컴퓨터의 경우, 먼저 디바이스 하드웨어가 자신이 사용할 어드레스를 특별한 레지스터에 기록해두어야 하고, 그러면 디바이스 드라이버는 그 어드레스를 알아내야만 한다. 이 두가지 작업은 소프트웨어로 자동으로 수행시키든, 아니면 특정한 파일에 손수 그 정보를 기록해두는 방법을 쓰든 반드시 완료되어야 한다. 두 작업중 어느 하나만을 시도하거나 완료시켰을 뿐이라면 문제가 발생한다.
수동으로 PnP 설정을 할 때 몇몇 사람들은 위의 두 작업중 하나만 해놓고는 왜 컴퓨터가 디바이스를 발견하지 못하는지 의아해한다. 예를 들면, 그들은 시리얼 포트에 특정 어드레스를 할당해준답시고 "setserial" 명령을 내리면서도, "setserial" 명령의 효과는 드라이버에게 어드레스를 알려줄 뿐임을 모르는 것이다. setserial 명령은 시리얼 포트 하드웨어내의 자체 레지스터에 어드레스를 셋팅하는 작업을 수행하지는 않는다. 만일 그 시리얼 포트 하드웨어가 당신이 setserial 명령으로 지시한 어드레스를 가지고 있지 않거나 아예 하드웨어에 어드레스가 셋팅되어있지 않은 상태라면 문제가 발생한다.
디바이스 드라이버가 어떤 어드레스를 사용하려면, 그전에 반드시 해당하는 물리적인 디바이스(가령 카드) 내에 그 어드레스가 셋팅되어있어야만 한다. 디바이스 드라이버들은 주로 컴퓨터가 시작되자마자 작동시작하는 것이 많기 때문에, 때때로 PnP 설정 프로그램이 카드내에 어드레스를 셋팅하기도 전에 드라이버가 먼저 카드에 엑세스를 시도하는 수가 있다(그 어드레스에 카드가 존재하는지 등등을 조사하려고). 이렇게 되면 카드가 있음에도 불구하고(하지만 카드가 어드레스를 갖고있지 않은 상태이므로), 카드를 찾을수 없다는 에러 메시지가 나타난다.
앞 문단들에서 설명한 I/O 어드레스에 관한 내용은 다른 자원(2.5절, 2.6절, 2.7절)에 대해서도 그대로 적용된다. 다음 세개 절에서 이들에 대해 설명한다.
메인 메모리내의 어드레스 공간을 할당받는 디바이스들도 많다. 때로는 이것을 "공유 메모리(shared memory)" 또는 "메모리 맵된 I/O(memory mapped I/O)" 또는 "IO 메모리" 라고 부르기도 한다. 이 메모리는 물리적으로는 디바이스상에 존재한다. 버스리소스를 논할 때는 그냥 "메모리"라고 부르기도 한다. 어떤 디바이스들은 이런 "메모리" 와 전통적인 I/O 어드레스공간을 둘다 사용하기도 한다.
이런 카드를 꽂으면 결과적으로 메인 메모리용 메모리 모듈을 꽂는 효과가 발생한다. 진짜 메인 메모리 칩들과 충돌하지 않도록 메모리맵 어드레스는 PnP 에 의해 상위 어드레스가 선택되어진다. 이 메모리는 ROM(Read Only Memory)일수도 있고 공유 메모리일 수도 있다. I/O 어드레스 공간이 디바이스와 CPU 에 공유되듯이, 공유 메모리도 (디바이스 드라이버를 구동시킴으로써) 디바이스와 CPU 가 공유하게된다. 이 공유 메모리는 디바이스와 메인 메모리간의 데이터 "전송" 수단으로 기능한다. 이것은 IO 지만 그 기능이 I/O 공간에서 이루어지는 것이 아니다. 카드와 디바이스 드라이버는 둘다 해당 공유 메모리의 어드레스를 알아야만 한다.
ROM 의 경우는 다르다. ROM 의 내용은 보통 그 디바이스가 사용할 프로그램(대개는 디바이스 드라이버)일 경우가 많다. 어쩌면 초기화코드일 뿐이라서 여전히 별도의 디바이스 드라이버가 필요할 수도 있다. 바람직스럽게도, 이 코드는 MS 윈도우즈 ?? 뿐만 아니라 리눅스에서도 동작할 것이다. 이것은 쉐도우(shadow) 될 필요가 있을지도 모른다. ROM 이 쉐도우된다는 것은 고속 동작을 위해 ROM의 내용을 메인 메모리로 복사해두는 것을 말한다. 일단 ROM 이 쉐도우되면, 그것은 더이상 "읽기 전용(read only)" 이 아니다.
이 설명을 읽은 뒤 더 자세한 것을 알고 싶다면 9.4절를 참고하라. 다음 내용은 일부러 극히 단순히 설명한 것이다: 어드레스 외에도, 인터럽트 번호(예를 들면 IRQ 5 등등)라는 것도 다루어야 한다. 이것은 IRQ(Interrupt ReQuest, 인터럽트 요구)번호라고 부른다. 디바이스 드라이버가 디바이스측에게 통신을 하기 위해서는 카드의 어드레스를 반드시 알고 있어야 함은 이미 설명하였다. 그렇다면 반대방향의 통신은 어떨까? 디바이스가 디바이스 드라이버에게 즉시 전해야 하는 내용이 있다면? 예를 들어, 디바이스가 메인 메모리를 목적지로 하는 대량의 바이트열을 외부에서 받았다고 치자. 이 경우, 디바이스는 거의 가득차가고있는 자신의 버퍼에서 바이트 열을 몽땅 퍼내어 메인메모리로 전송시켜줄 것을 디바이스 드라이버에게 요구할 필요가 있다. 또다른 예로, 외부로 전송해야할 바이트들을 다 전송한 디바이스가 디바이스 드라이버에게 작업을 끝마쳤음을 알리고 전송시킬 새로운 바이트들을 보내달라고 요청할 경우도 있다.
어떻게 하면 디바이스가 드라이버에게 즉각 신호를 보낼수 있을까? 메인 데이터버스는 뭔가가 이미 사용중이기 십상이므로 이를 사용할 수는 없다. 그대신, 디바이스는 인터럽트 전용으로만 사용되는 인터럽트 라인(버스의 일부이다)에 전압을 가한다. 이 라인은 보통 그 특정 디바이스 전용으로 예약되어져 있다. 이 전압신호를 인터럽트 요청(IRQ) 혹은 그냥 "인터럽트" 라고 부른다. PC 의 경우 인터럽트 라인은 16 개가 있어서, 이들은 각자 (간접적으로) 특정 디바이스 드라이버로 연결된다. 각 인터럽트 라인에는 고유의 IRQ(Interrupt ReQuest) 번호가 붙어 있다. 디바이스는 자신의 인터럽트를 그에 해당하는 올바른 라인으로 보내야 하고, 디바이스 드라이버는 올바른 라인에서 그 인터럽트 도착을 기다려야 한다. 특정 디바이스가 어느 라인을 통해 구조 요청을 보내는가는 그 디바이스에 기록저장되어있는 IRQ 번호에 의해 결정된다. 해당 디바이스 드라이버도 이 번호를 똑같이 알고있어야 한다. 그래야 해당번호의 IRQ 라인에서 구조 요청을 기다릴수 있기 때문이다.
일단 어떤 디바이스 드라이버가 해당 디바이스의 인터럽트를 받으면, 디바이스 드라이버는 인터럽트가 발생된 이유를 조사한 후, 그에따라 적절한 동작을 취해 인터럽트를 처리한다. ISA 버스의 경우, 각각의 디바이스는 대개 자신만의 유일무이한 IRQ 번호를 필요로한다. PCI 버스 및 기타 특별한 경우에는 IRQ 를 공유하는 것도 허용된다.
DMA 채널들은 전적으로 ISA 버스만을 위한 것이다. DMA 는 "Direct Memory Access(직접 메모리 억세스)" 를 의미한다. DMA 에서는 디바이스가 CPU 로부터 컴퓨터 메인 버스를 넘겨받아 이를 통해 바이트열을 메인 메모리에 직접 전송하는 것이 허용된다. DMA 를 쓰지않는 통상의 경우라면 CPU 는 이러한 전송작업을 다음 2 단계로 처리할 것이다:
해당 디바이스의 I/O 메모리 공간으로부터 바이트열을 읽어 CPU 자신에게 보낸다.
이 바이트열을 CPU 에서 메인 메모리로 보낸다.
DMA 를 사용하면 보통 위의 두 단계 과정이 디바이스에서 직접 메모리로 바이트열을 전송하는 한 단계 과정으로 처리된다.
PCI 버스는 사실 DMA 를 전혀 갖고있지 않지만, 그 대신 DMA 보다도 더 좋은 기능을 가지고 있다. 그것은 버스 마스터링(bus mastering)이라는 것이다. 버스 마스터링의 동작은 DMA 와 다소 유사하므로, 때로는 DMA 라고 불리기도 한다(예를 들면 하드디스크에서는 이를 "UltraDMA" 라고 부른다). 이 기능을 사용하면, 디바이스는 일시적으로 버스의 소유자(bus master)가 되어 마치 자신이 CPU 가 된 것처럼 바이트열을 전송할 수 있다. DMA 와는 달리 버스 마스터링은 채널 번호를 전혀 사용하지 않는다. 왜냐하면 PCI 버스의 구조상, PCI 하드웨어는 어느 디바이스가 현재의 버스 마스터이고 어느 디바이스가 장차 버스 마스터가 되기를 요청하고있는지를 알수있기 때문이다. 따라서 PCI 버스에 DMA 채널을 할당하는 경우는 없다.
ISA 버스상의 어떤 디바이스가 DMA 를 하려고 할 때에는, 그 디바이스는 인터럽트 요구때와 유사한 개념으로서 DMA 요청용으로 배선된 라인들에다 DMA 요구(DMA-request)를 발하게 된다. 사실, 인터럽트를 이용해 DMA 를 처리토록 할수도 있었겠지만, 그랬었더라면 다소의 시간지연이 불가피했을 것이다. 따라서, DMA 요구라 불리는 특수한 종류의 인터럽트를 쓰는게 더 빠르다. 인터럽트에서와 마찬가지로 DMA 요구들 각각에도 번호가 붙여져 있어, 이를 통해 어느 디바이스가 DMA 를 요구하고있는지를 식별할 수 있다. 이 번호를 DMA 채널이라 부른다. DMA 전송은 모두 메인 버스를 사용하므로(따라서 한번에 한 개의 채널밖에 동작할 수 없다) 사실은 각 번호의 채널들이 모두 동일한 물리적 채널을 사용하는 것이지만, "DMA 채널" 번호를 이용해 현재 "채널"을 사용하고 있는 것이 어떤 디바이스인지 알수 있다. 마더보드상에는 각 "채널"의 현재 상태를 저장하고 있는 하드웨어 레지스터들이 있다. 따라서 어떤 디바이스가 DMA 요구를 발하려면, 그 디바이스는 자신의 DMA 채널 번호를 알고있어야만 하며, 이 번호는 그 물리적인 디바이스상의 특별한 레지스터내에 저장되어져 있어야만 한다.
따라서, 디바이스 드라이버들은 자신이 제어하는 하드웨어와 어떤 방식으로든 연계되지 않으면 안된다. 이는 버스 리소스(I/O, 메모리, IRQ들, DMA 들)를 물리적인 디바이스와 디바이스 드라이버 소프트웨어 양쪽에 할당하는 것으로 이루어진다. 예를 들면, 하나의 시리얼 포트는 (가능한 4 가지 선택중에서) 단 2 개의 자원, 즉 IRQ 하나와 I/O 어드레스 하나만을 사용한다. 이 두개의 값은 디바이스 드라이버와 물리적 디바이스 양측에 모두 제공되어야 한다. 또한, 드라이버(그리고 그 디바이스)는 /dev 디렉토리밑에 특정한 이름을 제공받는다(예를 들면 ttyS1 등). 그 어드레스와 IRQ 번호는 물리적 디바이스에 의해 카드상의 설정 레지스터들 내에(마더보드에 실장된 경우는 마더보드상의 칩내에) 저장된다. 점퍼로 설정하는 경우에는, 점퍼의 조합 자체가 버스 리소스 설정을 디바이스의 하드웨어에 저장시키는 역할을 한다. 하지만 PnP 의 경우에는 대부분 PC 의 전원을 끄면 설정 레지스터의 데이터가 사라지게 되므로, PC 의 전원을 넣을 때마다 매번 버스 리소스 데이터를 각 디바이스에 새로 제공하여야 한다.
PC 의 설계구조상 IRQ, DMA 채널, I/O 어드레스, 메모리 영역의 수에는 제한이 있다. 만일 PC 의 디바이스 수가 몇개 안되고 이들 모두가 표준화된 버스 리소스(가령 특정 디바이스는 특정한 I/O 어드레스와 IRQ 번호를 가진다는 식의 표준)를 가졌더라면, 디바이스 드라이버를 디바이스에 연계시킬 때 아무런 문제도 없었을 것이다. 그랬더라면 PC 상의 각 디바이스는 다른 디바이스와 충돌하지 않는 고정된 리소스를 가졌을테니 말이다. 서로 다른 두 디바이스가 같은 I/O 어드레스를 갖거나 같은 IRQ 를 갖는 일 등도 없었을 것이다. 각 디바이스 드라이버들은 각자의 고유의 어드레스들과 IRQ 등등을 아예 프로그램속에 새겨넣어버렸을 테고, 그렇게만 되었더라면 모든 것이 한결 간단했을 것이다.
그러나 현실은 그렇지 못하다. 오늘날에는 디바이스들의 종류도 무척 많아서 충돌도 빈번할 뿐더러, 같은 종류의 디바이스를 여러개 사용해야할 경우도 생긴다. 예를 들면, 서로 다른 디스크 드라이브를 여러대 달거나, 네트웍 카드도 몇 개씩이나 달아야 하는 등의 경우도 있는 것이다. 이러한 이유에서, 디바이스는 어떠한 어드레스나 IRQ 등으로도 세팅가능해서 충돌을 피할 수 있는 유연성을 갖추어야 한다. 하지만 몇몇 IRQ 들과 어드레스들은 사실상 표준이 된 것도 있다. 가령 클럭이나 키보드에 대한 IRQ 및 어드레스들이 그러하다. 이런 디바이스들은 리소스 설정에 있어 유연성이 필요없다.
버스 리소스 할당에서의 충돌 문제외에, 디바이스 드라이버에게 드라이버의 버스 리소스를 잘못 가르쳐줘도 문제가 생긴다. 예를 들면, 디바이스는 IRQ 5 로 설정되어 있는데 실수로 당신이 설정 파일에 IRQ 4 라고 적어놓는 경우이다. 이것도 버스 리소스 할당 에러의 한 유형이다.
버스 리소스들을 제대로 할당했다면, 물리적인 하드웨어와 그에 대응하는 디바이스 드라이버 사이에 통신 채널이 확립된다. 예를 들면, 어떤 범위의 I/O 어드레스 영역(리소스)이 디바이스 드라이버와 하드웨어 양측에 할당되어진 경우, 양자간에 일방통행의 통신 채널이 확립된다. 드라이버 측은 디바이스에게 명령어와 정보를 보낼 수 있다. 사실은 드라이버측에서 디바이스의 레지스터를 읽어 정보를 얻어오는 방법도 가능하므로, 일방통행보다는 조금 더 나은 것이라 할수 있다. 그러나, 이 방법으로는 디바이스측에서 먼저 통신을 시작할 수는 없다. 디바이스쪽에서 먼저 통신을 개시하려면 디바이스는 자신의 드라이버에게 인터럽트를 보낼수 있는 IRQ 를 가져야 한다. 이 상태가 되어야 비로소 드라이버나 물리적 디바이스 어느 쪽이든 먼저 통신을 시작할 수 있는 양방향 통신 채널이 구축되는 것이다.
시리얼 포트에 케이블로 접속된 외부 디바이스들(예를 들면 외장형 모뎀)도 플러그 앤드 플레이라고 불리운다. 버스 리소스(IRQ 와 I/O 어드레스)를 필요로 하는 것은 시리얼 포트일 뿐으로서, 시리얼 포트에 꽂는 디바이스들에게는 버스 리소스가 할당되지 않는다. 그렇기 때문에 사실 이런 외부 디바이스에게는 PnP 가 필요없는 것이다. 그럼에도 불구하고, 그런 외부 시리얼 디바이스에 대해서도 PnP 명세서가 규정되어 있다.
PnP 운영체제는 이러한 외부 디바이스도 검출하여 그 디바이스의 모델 번호등을 읽어낸다. 그에 의해 해당 디바이스용 디바이스 드라이버를 찾아낼 수 있으므로, 예를 들면 /dev/ttyS1 상에 어떤 디바이스가 붙어있는지 당신이 직접 응용프로그램에게 알려주지 않아도 되게된다. 응용 프로그램에게 디바이스가 접속되어있는 시리얼 포트를 (설정 파일등을 사용해) 손수 알려주는 방법도 가능하므로 (디바이스의 모델 번호를 지정하는 것도 가능할지 모른다), PnP 의 이 "시리얼 포트" 기능이 반드시 필요한 것은 아니다. 리눅스가 이 기능을 지원하는지는 모르겠다. ??