시스템SW 아키텍처와 하드웨어 경계

1. 시간초과 뒤 버퍼를 지웠는데 장치가 계속 쓰면

센서 요청이 오래 걸려 응용 프로그램이 실패 화면을 표시했다. 개발자는 기다릴 필요가 없다며 버퍼를 해제했는데, 장치가 나중에 같은 메모리에 측정값을 쓰면 어떻게 될까? 사용자에게 응답하는 시간과 하드웨어가 자원을 더 이상 사용하지 않는 시점은 다를 수 있다.

가상 SS-SENSOR는 센서 자료를 읽어 해석하는 서비스다. 하드웨어를 제어하는 최소 드라이버, 커널의 보호·자원 관리, 사용자 공간의 변환·서비스를 나누고 같은 요청과 버퍼가 어느 경계를 통과하는지 살핀다. 실제 장치 드라이버를 작성·실행한 기록이 아니라 구조 판단을 위한 예다.

호출 경계와 입출력 완료를 구별했다

시스템 프로그래밍과 운영체제 인터페이스는 시스템콜의 보호 경계, 버퍼·DMA와 부분 입출력을 설명했다. 이번에는 CPU의 요청·장치의 전송·응답·자원 회수 시점을 같은 흐름에서 구분한다.

프로세스의 자원은 실행 주체와 연결된다

프로세스·스레드·실행상태의 프로세스는 독립 주소공간과 자원을 가진 실행 중 프로그램이었다. 사용자 서비스와 커널 책임을 분리할 때 이 경계를 넘는 권한·자료·오류를 함께 확인한다.

시스템 프로그래밍의 범위는 이미 배웠다

시스템 프로그래밍과 운영체제 인터페이스에서 번역·적재·보호 자원·입출력·프로세스 협력의 범위를 읽었다. 이 절은 각각의 기술을 반복 정의하지 않고 어떤 구성요소가 어떤 책임을 가져야 하는지 연결한다.

정확한 정의와 담당 경계

시스템SW 아키텍처는 운영체제·드라이버·실행환경 등 시스템 소프트웨어의 책임과 관계를 정하고, 응용 프로그램과 하드웨어 사이의 보호·자원·동시성·오류 경계를 조직한 구조다.

시스템콜·DMA·프로세스 등의 개념은 앞서 학습한 시스템 프로그래밍과 운영체제 인터페이스의 설명을 이어 쓴다. 이 절은 그 경계를 하나의 작동 구조로 연결하고 자원의 사용·완료·회수 조건을 판단하며 특정 커널 구현 전체를 새로 설계하지 않는다.

SS-SENSOR의 책임과 경로

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

사용자 요청은 검증된 호출로 커널 경계를 넘는다. 드라이버는 장치와 자원을 관리하고 완료·오류를 되돌린다. 대기 종료와 장치 접근 종료는 서로 다른 사건이므로, 버퍼 재사용 전에 원래 요청의 접근 종료와 동기화를 확인한다.

보호 경계와 장치 경로를 말로 확인하기

사용자 공간의 요청 처리와 자료 해석·업무 판단은 보호된 호출에서 전달하는 자료·결과·오류를 통해 커널과 연결된다. 커널은 자원·권한을 관리하고 최소 장치 드라이버가 명령·DMA 주소를 센서·전송 엔진에 전달한다. 장치의 완료·오류 인터럽트는 드라이버로 돌아온다.

세로선은 단순 함수 호출 비용만 뜻하지 않는다. 누구의 메모리를 언제 사용할 수 있는지, 호출자가 어떤 권한을 갖는지, 완료를 누가 확인하는지의 경계다. 논리 책임을 그렸으며 모든 운영체제가 같은 프로세스 배치를 갖는다는 뜻은 아니다.

커널·드라이버·실행환경은 서로 다른 변경을 맡는다

SS-SENSOR의 커널은 보호된 자원 접근과 스케줄링·메모리 등의 공통 관리를 맡고, 드라이버는 센서가 요구하는 명령·전송·완료 처리를 맡는다. 사용자 공간의 런타임과 라이브러리는 응용 코드가 호출할 경로를 제공하고, 서비스는 값의 해석과 업무 판단을 담당한다. 사용자 라이브러리가 감싼 호출 이름과 실제 특권 연산의 경계를 혼동하지 않는다.

파서의 단위 변환이 달라졌다는 이유로 장치의 인터럽트 처리까지 바꾸지 않고, 장치 프로토콜이 달라졌다고 업무상의 정상값 기준을 드라이버에 넣지 않는다. 필요한 권한과 자원 수명을 기준으로 책임을 나누고, 각 경계의 자료·오류 의미를 명시한다. 이 구분은 학습용 구조이며 구체적 제품의 기능 배치는 공식 설계와 실제 구현에서 확인한다.

모든 처리를 특권 안에 넣을 것인가

SS-SENSOR는 저수준 제어만 드라이버에 남기는 두 번째 안을 가정한다. 빠르거나 안전하다고 수치로 입증한 선택은 아니며 실제 요구와 측정으로 판단해야 한다. 특권 코드의 양만으로 완전한 보안이 결정되는 것도 아니다. 잘못된 경계의 재시도·자료 복사·동기화는 분리한 구조에서도 문제를 일으킨다.

2. 같은 메모리라도 장치가 보는 주소는 다를 수 있다

앞서 배운 DMA를 SS-SENSOR에 적용한다. CPU가 사용하는 가상 주소, 실제 메모리 위치, 장치가 전송에 사용하는 DMA 주소는 같은 값이라고 가정하지 않는다. Linux DMA 안내는 주소 변환이 개입할 수 있으며 DMA API에서 반환한 장치용 주소를 사용하도록 설명한다. [SRC-SS-DMA]

CPU 포인터를 숫자로 바꾸어 장치 주소로 넘기는 것은 올바른 DMA 매핑을 확인한 것과 다르다. 허용되는 메모리 종류·장치 주소 범위·전송 방향을 확인하고 매핑 결과의 오류도 처리한다. Linux에서는 dma_mapping_error 같은 API의 계약을 따르며 장치가 접근할 수 없는 매핑을 성공 경로로 이어 보내지 않는다.

요청 상태와 자원 상태를 두 줄로 따라간다

버퍼의 사용·동기화·회수는 요청 대기와 별개다 · 상태 따라가기

버퍼를 할당하고 장치가 사용할 매핑을 준비한다. 모든 단계에서 DMA 버퍼·소유·사용·회수의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

이 자원 경로는 요청의 성공·오류·결과 미확인과 따로 추적한다. 시간초과가 장치 정지나 해제 허가를 뜻하지 않는다. 실제 매핑 방식·방향·동기화와 종료 순서는 공식 API·장치 계약으로 구체화한다.

이 예의 조건

• 할당, 매핑, 장치 사용, 완료 확인 및 동기화, CPU 사용, 회수의 자원 상태를 순서대로 따르는 부분 경로다. 요청 시간초과만으로 회수 상태에 가지 않는다.
• 할당→매핑→장치 사용→완료 확인·동기화→CPU 사용→회수를 자원 상태로 추적한다. 각 전이는 결과 확인, 접근 인계, 완료·중단 확인, CPU 인계, 접근 종료 조건을 갖는다. 요청 시간초과 자체는 장치 정지나 회수 허가가 아니다. 전체 오류 전이는 별도다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
할당·매핑 버퍼를 할당하고 장치가 사용할 매핑을 준비한다.	값·보충 정보 DMA 버퍼·소유: 할당·매핑 완료 사용·회수: 장치 사용 전	변화·이유 준비되지 않은 버퍼를 장치에 공개하지 않는다.
장치 소유 장치가 사용 중이면 CPU 사용·회수를 제한한다.	값·보충 정보 DMA 버퍼·소유: 장치 소유 사용·회수: CPU 사용·해제 보류	변화·이유 timeout만으로 장치 사용이 끝났다고 보지 않는다.
완료·동기화 실제 장치 완료와 필요한 동기화를 확인한다.	값·보충 정보 DMA 버퍼·소유: 완료 확인 사용·회수: CPU 읽기 준비	변화·이유 응답 대기와 메모리 소유 조건은 다르다.
CPU 사용 뒤 회수 CPU가 준비된 내용을 사용하고 마지막 사용 뒤 버퍼를 회수한다.	값·보충 정보 DMA 버퍼·소유: CPU 사용→회수 사용·회수: 실제 사용 종료	변화·이유 매핑·소유·완료 조건을 지킨 뒤 해제한다.

버퍼의 사용·동기화·회수는 요청 대기와 별개다 · 상태 따라가기

버퍼를 할당하고 장치가 사용할 매핑을 준비한다. 모든 단계에서 DMA 버퍼·소유·사용·회수의 위치를 유지하며 값과 허용 조건을 함께 확인합니다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

이 자원 경로는 요청의 성공·오류·결과 미확인과 따로 추적한다. 시간초과가 장치 정지나 해제 허가를 뜻하지 않는다. 실제 매핑 방식·방향·동기화와 종료 순서는 공식 API·장치 계약으로 구체화한다.

이 예의 조건

• 할당, 매핑, 장치 사용, 완료 확인 및 동기화, CPU 사용, 회수의 자원 상태를 순서대로 따르는 부분 경로다. 요청 시간초과만으로 회수 상태에 가지 않는다.
• 할당→매핑→장치 사용→완료 확인·동기화→CPU 사용→회수를 자원 상태로 추적한다. 각 전이는 결과 확인, 접근 인계, 완료·중단 확인, CPU 인계, 접근 종료 조건을 갖는다. 요청 시간초과 자체는 장치 정지나 회수 허가가 아니다. 전체 오류 전이는 별도다.
• 이 원문의 교육용 사례·조건 안에서 상태를 대조합니다. 실제 구축·실험 결과나 원문에 없는 성능 보장을 추가하지 않습니다.

예의 값과 변화

관찰·상황	값·보충 정보	변화·이유
할당·매핑 버퍼를 할당하고 장치가 사용할 매핑을 준비한다.	값·보충 정보 DMA 버퍼·소유: 할당·매핑 완료 사용·회수: 장치 사용 전	변화·이유 준비되지 않은 버퍼를 장치에 공개하지 않는다.
장치 소유 장치가 사용 중이면 CPU 사용·회수를 제한한다.	값·보충 정보 DMA 버퍼·소유: 장치 소유 사용·회수: CPU 사용·해제 보류	변화·이유 timeout만으로 장치 사용이 끝났다고 보지 않는다.
완료·동기화 실제 장치 완료와 필요한 동기화를 확인한다.	값·보충 정보 DMA 버퍼·소유: 완료 확인 사용·회수: CPU 읽기 준비	변화·이유 응답 대기와 메모리 소유 조건은 다르다.
CPU 사용 뒤 회수 CPU가 준비된 내용을 사용하고 마지막 사용 뒤 버퍼를 회수한다.	값·보충 정보 DMA 버퍼·소유: CPU 사용→회수 사용·회수: 실제 사용 종료	변화·이유 매핑·소유·완료 조건을 지킨 뒤 해제한다.

응용 프로그램의 시간초과는 첫 줄의 기다림에 관한 사실이다. 그 시점에 둘째 줄이 어디까지 갔는지는 별도로 확인해야 한다. 요청 대기를 끝냈다는 이유만으로 장치가 사용하는 버퍼를 해제하지 않는다. 종료·취소에서도 장치 사용이 끝났거나 안전하게 중단됐다는 근거가 필요하다.

소유자는 여기서 메모리의 법적 소유자가 아니라 해당 단계에서 접근·수정·회수를 책임지는 주체다. 매핑과 전송 방향·길이를 추적하고, 완료 이전 CPU 접근이나 이중 해제를 막는 상태 규칙을 둔다. 실제 API 호출 순서는 장치·매핑 방식의 공식 계약으로 구체화한다.

스트리밍 매핑은 CPU와 장치 사이의 인계 조건을 갖는다

Linux의 스트리밍 DMA 매핑은 장치와 CPU가 번갈아 버퍼를 사용하는 상황에서 동기화가 필요할 수 있다. 같은 매핑을 재사용할 때 CPU가 데이터를 읽거나 바꾸기 전에 필요한 CPU 측 동기화를 하고, 장치에 다시 넘기기 전에 장치 측 동기화 조건을 지킨다. 마지막 DMA 활동이 끝난 뒤 매핑을 해제한다. [SRC-SS-DMA]

CPU 동기화·장치 동기화를 무조건 같은 순서로 두 번 호출하라는 뜻은 아니다. 방향과 어느 쪽이 실제로 수정했는지, 코히런트 매핑인지에 따라 API 계약이 다르다. 버퍼 할당 수명, 매핑 수명, 각 전송 수명을 하나의 성공 플래그로 합치지 않는다.

보인다는 것과 순서대로 보인다는 것은 다르다

메모리 장벽은 정한 종류의 메모리 접근이 허용되지 않는 순서로 관찰되는 것을 막기 위해 사용하는 순서 보장 수단이다. 어떤 접근과 관찰자에 대해 무엇을 보장하는지는 아키텍처와 API의 종류에 따라 다르다. 캐시 내용을 모두 지우거나 자원의 소유권을 자동으로 넘기는 만능 연산은 아니다.

SS-SENSOR의 가상 전송 디스크립터(descriptor)는 전송 주소·길이와 준비 완료 표시를 담는 자료구조다. 장치가 준비 표시를 먼저 보고 아직 기록되지 않은 주소·길이를 읽지 않게 순서를 보장해야 한다. Linux DMA 문서도 코히런트 매핑이라고 해서 메모리 장벽이 필요 없다는 뜻은 아니라고 설명한다. [SRC-SS-DMA]

캐시 일관성, 접근 순서, 여러 실행 주체의 배타적 수정은 서로 다른 조건이다. 장벽만 넣고 두 생산자가 같은 슬롯을 예약하도록 두면 경쟁은 남는다. 플랫폼의 적절한 I/O·메모리 접근 API와 동기화 규칙을 선택하고 실제 경계에서 검증한다.

3. 완료 알림을 처리하는 문맥도 계약이다

센서의 완료 인터럽트는 요청을 제출한 사용자 스레드와 다른 문맥에서 발생할 수 있다. Linux request_threaded_irq의 기본 처리기는 하드 인터럽트 문맥에서 실행되며, 필요한 처리를 별도의 인터럽트 스레드로 넘길 수 있다. 이 구분 없이 기다릴 수 있는 함수나 락을 아무 곳에서 호출하지 않는다. [OS-LINUX-GENERICIRQ-ROLLING]

SS-SENSOR의 빠른 처리 경로는 장치 상태 확인과 필요한 알림에 집중하고, 긴 자료 해석은 적절한 실행 문맥으로 넘긴다는 구조를 가정한다. 실제로 어떤 동작이 가능한지는 커널 설정·API·락 계약을 확인한다. 인터럽트 등록 직후에도 처리기가 실행될 수 있으므로 공유 상태를 준비하지 않은 채 먼저 활성화하지 않는다.

SS-Q1: 유한한 큐에는 예약 규칙이 필요하다

가상 큐는 8슬롯이며 슬롯당 4,096바이트다. 자료 영역은 8×4,096=32,768바이트이고 관리 정보·정렬·별도 복사 공간은 제외했다. 현재 6슬롯이 사용 중이면 새 요청 3건 중 2건만 예약하고 나머지 1건은 거절하거나 미리 정한 대기 정책으로 보낸다.

두 생산자가 동시에 “6개 사용 중이니 2개씩 가능”이라고 판단하고 각각 2개를 확정하면 10개가 된다. 빈 공간 확인과 슬롯 예약의 상태 변경을 하나의 동기화된 결정으로 처리해야 한다. 이 예의 정상 정책은 먼저 2개를 예약한 뒤 다른 생산자가 갱신된 8개를 보고 추가 예약을 거부하는 것이다. 대기·거절·손실의 선택은 요구와 함께 정하며 활성 버퍼를 조용히 덮어쓰지 않는다.

완료 이벤트가 늦거나 두 번 올 때

가상 요청 R7의 완료를 기록한 뒤 중복 알림이 오면 같은 버퍼를 다시 해제하면 안 된다. 장치 재설정 뒤 이전 요청의 늦은 알림이 새 요청에 적용되는 것도 막아야 한다. 요청 식별과 세대·상태를 어떻게 대응시키는지 문서화하고 현재 진행 중인 요청인지 확인한다.

이 예에서 완료 처리의 종료 상태는 한 번만 확정하며, 매핑 해제·버퍼 반환도 그 상태 전이와 연결한다. 단, 메모리에 플래그 하나를 쓴다고 동시 알림과 종료가 안전해지는 것은 아니다. 어떤 락·원자 연산과 하드웨어 확인이 필요한지는 실제 구현의 경쟁 상황에서 검증해야 한다.

종료는 새 작업을 막고 남은 사용을 끝내는 절차다

SS-SENSOR의 종료 조건은 ① 새 제출을 차단하고, ② 진행 중 DMA를 완료 또는 안전하게 중단시키고, ③ 인터럽트·후속 작업 등 접근 주체가 빠져나왔음을 확인한 뒤, ④ 매핑·버퍼·장치 자원을 회수하는 것이다. 장치 규약에 따라 실제 동작 순서를 구체화하되 회수된 자원에 도달할 수 있는 실행 주체가 남지 않아야 한다.

Linux의 disable_irq_nosync는 이미 실행 중인 인터럽트 처리기의 종료를 기다리지 않는다. free_irq가 처리기 종료를 기다린다는 사실도 별도로 예약한 모든 후속 작업이나 DMA까지 자동 종료했다는 뜻은 아니다. 이들을 같은 보장으로 확대하지 않는다. [OS-LINUX-GENERICIRQ-ROLLING]

공유 인터럽트, 장치 오류, 타임아웃과 종료 중 잠금 순서를 실제 계약에 맞게 시험한다. 종료 플래그 설정과 화면 표시만으로 하드웨어 정지 증거를 대신하지 않는다.

상태별 통과 조건을 간단한 표로 만든다

이 표는 가상 설계의 불변조건이다. 실제 API 함수가 반환한 값과 하드웨어 관찰을 연결해야 실행 증거가 된다. 입력 상태를 사람이 올바르다고 채운 표를 검사하는 프로그램은 실제 장치의 안전성을 시험한 것이 아니다.

성능 조정이 바꾸는 책임을 확인한다

복사 횟수를 줄이기 위해 버퍼를 공유하면 전달 비용을 줄일 가능성이 있지만 접근 권한·수명·동기화 책임이 더 중요해진다. 큐를 키우면 순간 요청을 더 받을 수 있지만 메모리와 대기시간·종료 대상을 늘린다. 짧은 인터럽트 처리와 늦춘 작업 사이에서도 응답 지연과 문맥의 제약을 비교한다.

지연시간 하나를 최적화하다 정지·회수 조건을 약화시키지 않는다. 실제 요구 부하·장치·자료 크기에서 지연·오류·자원 점유를 관찰하고, 안전 조건을 만족하는 대안들 사이에서 비용을 비교한다. 측정하지 않은 수치를 “사용자 공간이라 느림” 또는 “DMA라 빠름” 같은 말로 대신하지 않는다.

구조 문서와 검증 증거를 묶는다

구성요소별 권한·자료 계약, 요청과 버퍼 상태, 주소·길이·방향, 락·실행 문맥, 오류와 종료 조건을 문서화한다. 구현 판본별 시험에는 매핑 실패, 큐 포화, 부분 결과, 중복·지연 완료, 종료 중 인터럽트와 후속 작업을 포함한다.

논리 불변조건 검사는 설계의 반례를 찾는 도구이며, 하드웨어·동시성 시험과 구분한다. 커널 문서와 장치 명세를 읽었다는 기록도 해당 장치에서 검증을 실행한 증거는 아니다. 다음 절은 이 책임과 검증 조건을 다른 구현자도 같은 뜻으로 읽을 수 있는 기술문서에 옮긴다.

공식 시스템SW 아키텍처 범위

운영체제·드라이버·실행환경의 구조를 보호·자원·동시성·오류 경계로 설명하고 SS-SENSOR에서 구성요소·인터페이스·자원 수명·종료의 결정을 연결한다. 공식 출제기준의 시스템SW 아키텍처 설계 범위를 설명하되, 임베디드·전체 커널 구현 또는 실장치 성능 검증까지 충족했다고 확대하지 않는다.

독립 연습 — 시간초과 뒤의 완료 이벤트를 누구의 자원으로 읽는가

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

SS-SENSOR의 요청 대기가 시간초과했다. 그 버퍼는 아직 장치 사용 중이고 늦은 완료 이벤트와 후속 작업이 남아 있다. 호출자는 같은 메모리를 새 요청에 즉시 재사용하려 한다.

• 대기 종료, 장치 접근 종료, 회수 완료를 각각 판정하라.
• 재사용 전에 확인할 접근과 요청 식별의 조건을 적어라.

풀이와 오답 교정 보기

대기 종료만 확인됐다. 장치가 쓰는 중이고 후속 접근이 남아 있으므로 회수 완료도 아니다. 새 제출을 차단하고 장치·IRQ·후속 작업의 기존 접근을 끝내며 방향과 API에 맞는 동기화를 확인한 뒤 회수·재사용한다. 늦은 이벤트를 새 요청의 완료로 오인하거나 같은 자원을 두 번 정리하지 않도록 해당 요청과 자원 상태를 함께 확인한다. 시간초과 자체는 장치 정지나 버퍼 반환의 근거가 아니다.

응답 실패를 회수 허가로 썼다면 요청과 자원 상태, IRQ 처리만으로 모든 접근 종료라고 썼다면 종료 절차와 상태별 근거를 대조한다.

자체 10점 문제

시스템SW 아키텍처에서 보호 경계와 자원 수명을 설명하고, DMA 완료·시간초과·메모리 회수를 구분해야 하는 이유를 제시하시오.

실제 기출이 아닌 자체 작성 문제다. 앞서 배운 본문의 근거와 경계를 유지하여 설명·비교·판단을 연결한다.

10점 풀이와 답안 구성 보기

10점 답안 목차

1. 책임·보호 경계
2. 주소와 인계
3. 시간초과와 회수
4. 종료와 검증

10점 답안 도식

보호 경계 그림의 사용자 요청 → 검증된 호출 → 드라이버·장치 경로와 버퍼 상태 그림을 함께 사용한다. 시간초과 ≠ 장치 정지이며 완료·접근 종료와 필요한 동기화가 확인되어야 회수할 수 있다.

화살표는 본문에서 가르친 책임과 증거의 연결이며 실제 실행 기록이 아니다.

10점 모범답안

1. 책임·보호 경계

필요 권한과 자원 수명을 기준으로 커널의 공통 관리, 드라이버의 장치 제어, 사용자 서비스의 자료 해석을 나눈다. 함수 이름이 아니라 경계를 넘는 자료·오류·권한을 확인한다.

2. 주소와 인계

CPU 포인터와 장치 DMA 주소를 구분하고 매핑 결과·방향·길이를 확인한다. 전송 수명과 매핑 수명은 다르며 CPU·장치 사이의 접근 인계에는 적절한 동기화가 필요하다.

3. 시간초과와 회수

요청 시간초과는 기다림의 종료이지 장치 사용의 종료가 아니다. 장치가 더 이상 접근하지 않는다는 근거 없이 버퍼를 해제하지 않고 완료·취소 상태와 회수를 연결한다.

4. 종료와 검증

새 제출을 막고 DMA·인터럽트·후속 작업의 남은 사용을 끝내 자원 재접근이 없음을 확인한다. 설계 표와 실제 동시성·장치 시험을 구분하며 단순 플래그나 함수 반환으로 전체 종료를 추정하지 않는다.

자체 25점 문제

가상 SS-SENSOR의 시스템SW 구조를 설계하시오. 사용자 서비스·커널·드라이버의 책임, DMA 자원 수명, SS-Q1의 큐 계산과 동시 예약, 오류·종료·검증 방안을 제시하시오.

실제 기출이 아닌 자체 작성 문제다. 앞서 배운 본문의 근거와 경계를 유지하여 설명·비교·판단을 연결한다.

25점 풀이와 답안 구성 보기

25점 답안 목차

1. 구조와 선택
2. DMA 주소·수명
3. 순서·실행 문맥
4. SS-Q1 큐
5. 오류·종료
6. 근거와 후속 검증

실제 도식을 연결하는 답안 논증 순서

1. 책임·권한을 정하고 호출·주소·길이 계약에 연결한다.
2. 버퍼의 인계·완료 상태마다 동기화·실행 문맥·상태 규칙을 확인한다. 실패·포화·경쟁을 각각 점검한다.
3. 새 제출 차단 → 잔여 접근 종료 → 회수의 종료 조건을 지킨다.

화살표는 본문에서 가르친 책임과 증거의 연결이며 실제 실행 기록이 아니다.

25점 모범답안

1. 구조와 선택

장치 제어는 최소 드라이버, 공통 보호·자원 관리는 커널, 자료 해석과 업무 판단은 사용자 서비스로 분리한다. 권한·수명·오류 경계를 문서화하고 전달 비용과 오류 영향을 비교하되 실제 성능을 측정한 선택이라고 하지 않는다.

2. DMA 주소·수명

CPU 가상 주소를 DMA 주소와 동일시하지 않고 매핑 오류를 확인한다. 할당·매핑·장치 사용·완료·CPU 접근·회수를 나누며 시간초과만으로 장치 사용 버퍼를 해제하지 않는다.

3. 순서·실행 문맥

코히런트 매핑의 가시성, 메모리 접근 순서, 배타적 수정은 다른 조건이다. 전송 디스크립터의 주소·길이 필드가 준비 표시보다 먼저 관찰되도록 적절한 API를 사용하며, 하드 인터럽트와 별도 스레드의 문맥을 구분한다.

4. SS-Q1 큐

8슬롯×4,096바이트는 자료 영역 32,768바이트다. 6슬롯 사용 중이면 3건 중 2건만 예약하고 1건은 정한 정책으로 처리한다. 두 생산자가 옛 값 6을 읽고 각각 2개씩 예약해 10개가 되는 반례를 막도록 확인과 예약을 동기화한다.

5. 오류·종료

지연·중복 완료는 요청 식별과 현재 상태를 확인해 한 번만 반영한다. 새 제출을 차단하고 DMA·인터럽트·후속 작업의 접근 종료를 확인한 뒤 매핑·버퍼를 회수한다. IRQ 대기 보장을 모든 장치 작업의 종료로 확대하지 않는다.

6. 근거와 후속 검증

구조·주소·방향·길이·문맥·락·종료 계약을 실제 판본과 연결한다. 실패·포화·중복·종료 중 접근 시험을 수행하고 설계 상태 검산과 실제 하드웨어 검증을 구별한다.

다시 읽을 핵심

시스템SW 구조의 경계는 상자 사이의 선만이 아니라 권한·주소·동시성·자원 수명의 약속이다. 기다림과 완료, 가시성과 순서, IRQ 대기와 모든 접근의 종료를 구분하여 실제로 회수해도 되는 상태를 판단한다.

출처와 검증의 경계

SRC-SS-DMA — Linux kernel development community, Dynamic DMA mapping Guide. 판본: Named primary HTML passages observed 2026-09-06. 확인: 2026-09-06. 위치: CPU and DMA addresses; mappings; synchronization and unmapping 원문: Linux DMA mapping Guide

OS-LINUX-GENERICIRQ-ROLLING — The Linux Kernel documentation project, Linux generic IRQ handling. 판본: rolling documentation checked 2026-09-01. 확인: 2026-09-01. 위치: request_threaded_irq; disable_irq_nosync; free_irq 원문: Linux generic IRQ handling

한국어 설명·수치·식의 적용 예·도식·문제·답안은 독립 작성했다. 원문의 코드·그림·실험 결과를 복제하지 않는다. 확인한 명시 범위의 원리와 도구 규칙만 사용하며, 실제 운영 서비스·모델 학습·독립 사람 검수의 성공으로 확대하지 않는다. 권리·기술·독자 검수와 발행 승인은 남아 있다.

직접 연습: 마지막 접근 시각, 완료의 식별, 예약 순서를 따로 추적한다.

아래 시각과 상태는 설계 조건을 적용하는 가상 자료이다. 실제 커널·장치의 완료 여부나 동시성 안전성을 측정한 결과는 아니다.

1. SS-L. 새 제출을 5 ms에 차단했고 요청 대기도 그때 시간초과했다. 장치의 버퍼 접근 종료를 9 ms에 확인했다. 실행 중 IRQ 처리기의 마지막 접근은 10 ms, 예약된 후속 작업의 마지막 접근은 12 ms에 끝났다. 이후 이 세 주체의 재접근은 없고 다른 접근 주체도 없다는 것이 이 문제의 전제다. 9 ms와 10 ms에 각각 무엇이 남아 있는가? 모든 기존 접근이 끝나는 가장 이른 시각과 요청 대기 종료 이후의 시간 차이는 얼마인가? 그 시각만 계산하면 매핑 해제·버퍼 회수까지 완료됐다고 할 수 있는가?
2. SS-G. 이전 요청 R7·세대 41의 장치 접근과 후속 접근은 이미 안전하게 종료했다. 같은 슬롯은 새 요청 R8·세대 42가 사용 중이다. 자원 포인터가 없는 식별 정보만 담은 통지가 (R7,41), (R8,42), (R8,42) 순서로 도착한다. 이번 연습의 완료 상태 규칙은 ‘현재 요청·세대와 일치하고 진행 중일 때만 한 번 완료로 전이한다’이다. 각 통지를 판정하라. 완료 전이는 몇 번인가? 슬롯 번호만 같다는 이유로 첫 통지를 R8의 완료로 처리하면 어떤 문제가 생기는가? 올바른 식별만으로 실제 자원 회수 조건도 충족되는가?
3. SS-Q. 별도 큐는 10슬롯이고 슬롯당 자료 영역은 4,096바이트다. 현재 7슬롯을 사용 중이다. 생산자 A는 2건, B는 3건을 요청한다. 정책은 ‘남은 슬롯만 예약하고 나머지는 대기로 보낸다’이다. 두 생산자가 모두 옛 값 7만 보고 자기 요청을 전부 확정하면 사용 슬롯은 몇 개인가? 확인과 예약을 동기화하여 A 다음 B로 처리할 때와 B 다음 A로 처리할 때 각 생산자의 예약·대기 수를 구하라. 총 자료 영역과 최종 사용 슬롯도 계산하라. 두 순서가 모두 용량을 지킨다고 해서 공정한 배분이 보장되는가?

접근 종료·요청 세대·동기화된 예약의 풀이

1. SS-L — 가장 늦은 접근 주체까지 확인한다. 9 ms에는 장치 접근이 끝났지만 IRQ 처리기와 후속 작업이 남는다. 10 ms에는 IRQ 처리기까지 끝났지만 후속 작업은 12 ms까지 접근한다. 주어진 전제에서 모든 기존 접근이 끝나는 가장 이른 시각은 max(9,10,12)=12 ms이고, 대기 종료 5 ms와의 차이는 7 ms이다.

12 ms는 이 문제에서 남은 접근이 없다는 조건이 성립하는 시각이다. 필요한 방향별 동기화, 매핑 해제, 버퍼 반환을 실제 API 계약에 따라 수행했다는 뜻은 아니다. 그 절차와 상태 전이를 확인해야 회수 완료를 말할 수 있다. 실제 환경에서 접근 종료가 미확인이면 계산표에 끝났다고 채우지 않고 안전한 중단·관찰 근거를 확보한다.

2. SS-G — 현재 요청·세대·상태를 함께 확인한다. 첫 통지 R7·41은 이전 요청이므로 R8·42의 상태를 바꾸지 않는다. 두 번째 통지 R8·42는 현재 진행 중 요청과 일치하므로 완료로 한 번 전이한다. 세 번째는 같은 완료의 중복이므로 다시 전이하거나 같은 자원을 다시 정리하지 않는다. 완료 전이는 총 1번이다.

슬롯 번호만 보고 첫 통지를 적용하면 실제로 진행 중인 R8을 이전 R7의 알림으로 끝내는 오류가 생긴다. 요청 식별자·세대·현재 상태의 검사는 이를 구별하기 위한 조건이다. 다만 이 사례는 이전 요청의 실제 접근이 종료됐다는 전제를 이미 두었다. 세대 번호가 다르다는 이유만으로 남아 있는 DMA나 후속 접근을 안전하게 만드는 것은 아니다. 완료 식별, 장치 접근 종료, 동기화와 회수는 각각 확인한다. 실제 동시 통지의 상태 전이는 적절한 동기화로 보호해야 한다.

3. SS-Q — 용량 준수와 배분 정책은 다른 조건이다. 자료 영역은 10×4,096=40,960바이트이며 관리 정보·정렬·별도 복사 공간은 제외했다. 두 생산자가 옛 사용량만 보고 전부 예약하면 7+2+3=12슬롯으로 용량을 2슬롯 초과한다.

A부터 처리하면 A가 2건을 예약하여 사용량은 9가 된다. B는 갱신된 남은 1슬롯만 예약하고 2건을 대기로 보내므로 최종 사용량은 10이다. B부터 처리하면 B가 3건을 예약하여 사용량은 10이 된다. A는 0건 예약·2건 대기이다. 두 경우 모두 새 예약은 총 3건이고 대기는 총 2건이다.

확인과 예약을 동기화하면 이 예의 초과 예약을 막을 수 있지만, A·B의 몫은 처리 순서에 따라 달라진다. 공정성이나 대기 시간 보장은 별도의 순서·우선순위·대기 정책을 정하고 검증해야 한다. 이 순차 계산은 경쟁 상황의 반례와 정책 차이를 설명하며 실제 락·원자 연산·하드웨어 시험을 대신하지 않는다.