Q) 지금 사용하는 v4.4 (커스터마이즈 개발이 되어있는) -> v4.9 까지의 .patch 를 소스에 적용하면
커널의 안정적인 동작을 보장하는 것은 머지한 개발자 몫인가요?
 
A) 네, 머지한 개발자의 몫입니다. 머지한 다음에 제대로 부팅하지 못하면 스스로 해결해야 합니다.
 
Q) 머지하면서 이해가 가능한가요? 함수 하나 하나보기도 힘든데 ㅜ 그냥 기계적인 머지만 해도 안정적인 커널이 보장될나요? (잘 모름)
 
A) '머지하면서 이해'는 사실 상 불가능합니다. 리눅스 커널을 구성하는 기능이 다양하고 코드의 복잡도가 낮아져서 패치를 보고 바로 이해하는 것은 어렵습니다. '기계적인 머지만 해도 안정적인 커널이 보장'은 거의 불가능합니다. 
 
참고로 커널 버전을 통채로 업그레이드하는 작업은 배포판 업체(레드헷, 구글 안드로이드) 혹은 SoC 업체(퀄컴, 엔비디아) 내부 커널 개발자들이 진행합니다.
 
Q) 기존 v4.4 에서 만든 기능을 기존 v4.4 와 비교, 따로 빼서(우리꺼) 패치 v4.9 기반에서 넣는다. (이게 더 볼 량이 적지 않을까요?)
 
A) 이렇게 진행할 수도 있는데요. 특정 태그의 커밋을 통채로 머지하는 Git Merge를 진행합니다.
 
Q)  커널 코드를 직접 수정하지 않아도 되는 부분은 가능하면 처음부터 모듈 프로그래밍으로 modprobe .*.ko module 을 사용한다.
 
A) 모든 경우에 대응할 수 있습니다. 물론 커널 모듈 드라이버가 인터페이스를 정확히 맞춰서 개발한다면 말이죠.
 
Q) 유저에서 BPF 피쳐를 사용하여 커널 관련 기능을 사용하는 추세라서 (예를 들어, SentinelOne 같은 특정 분야 1위 기업) 커널 코드 수정에 필수적인 부분? 이런 점도 궁금하네요.
 
A) v5.17 부터 BPF 기능을 추가로 확장한 BPF CO-RE를 지원합니다. 조금 더 자세한 내용은 아래 링크를 참고하세요.
 

+ Recent posts