인터럽트 발생시 일반적으론 다음과 같은 절차를 따름니다.
mask(irq)
call(interrupt_handler)
unmask(irq)
disable_irq() 도 결국은 mask(irq) 를 구현하는 것이지요.
원칙적으로
interrupt_handler 내부에서 자기 irq 를 disable 하고 싶을 때 disable_irq_nosync() 를 사용해야 하긴 하지만,
이것만으로는 2% 부족합니다. irq core 에서 unmask() 하는 것도 막야하니까요. 이런저런 트릭들이 사용됩니다.
부가적으로,
핸들러가 종료되기를 기다렸다가 disable_irq() 를 한다면 이미 늦을 지도 모릅니다.
그 새 인터럽트가 또 발생해서 핸들러가 다시 돌 수 있거든요.
disable_irq_nosync() 를 먼저 하고 핸들러가 종료되기를 기다리는 게 안전합니다.
disalbe_irq() 의 구현 예를 살펴보세요.
구지 따지자면 disable_irq_nosync() 가 기본이고, disable_irq() 는 부가적인 설비쯤 되는 셈.
인터럽트 발생시
인터럽트 발생시 일반적으론 다음과 같은 절차를 따름니다.
mask(irq)
call(interrupt_handler)
unmask(irq)
disable_irq() 도 결국은 mask(irq) 를 구현하는 것이지요.
원칙적으로
interrupt_handler 내부에서 자기 irq 를 disable 하고 싶을 때 disable_irq_nosync() 를 사용해야 하긴 하지만,
이것만으로는 2% 부족합니다. irq core 에서 unmask() 하는 것도 막야하니까요. 이런저런 트릭들이 사용됩니다.
부가적으로,
핸들러가 종료되기를 기다렸다가 disable_irq() 를 한다면 이미 늦을 지도 모릅니다.
그 새 인터럽트가 또 발생해서 핸들러가 다시 돌 수 있거든요.
disable_irq_nosync() 를 먼저 하고 핸들러가 종료되기를 기다리는 게 안전합니다.
disalbe_irq() 의 구현 예를 살펴보세요.
구지 따지자면 disable_irq_nosync() 가 기본이고, disable_irq() 는 부가적인 설비쯤 되는 셈.
댓글 달기