모니터링 기간: 2026-10-26 08:00 ~ 2026-10-27 08:00 (베이징 시간, 24시간)

출처: RT-Thread 공식 뉴스 인터페이스 및 커뮤니티 기사 인터페이스, GitHub(메인 저장소 commits / PR / Issue / releases / tags, RT-Thread/sdk, vscode-rt-smart, packages, pkgs-test, topic:rt-thread 생태계 검색), Google News 집계(중영문 6개 쿼리, 프록시 경유), HN Algolia, 업계 미디어(EE Times China RT-Thread 칼럼) 및 벤더 채널 검증(상세는 부록 출처 목록 참조)

이번 호 인덱스

    1. 커널 및 버전 동향
      • 메인라인 24시간 커밋 없음, 마지막 커밋은 여전히 lwIP 루프백, 조직 내에서는 VS Code 확장만 움직임 (10-26)
      • 병합 대기열 13개 제안 같은 날 갱신, 신규는 Renesas RA6W1 한 건뿐 (10-26)
    1. 보안 및 안정성 후속 조치
      • signalfd의 전역 카운트 범위 초과: 11번째 호출부터 커널 포인터를 힙 블록 밖에 기록 (10-26)
      • musl 스레드 연결 리스트의 동시 종료 시 use-after-free: futex 락이 상호 배제 역할을 하지 못함 (10-26)
      • 시간 서브시스템 두 곳 수정이 성숙 버전으로 전환: settimeofday 강제 변환 제거, gmtime_r 음수 타임스탬프 처리 (10-26)
      • ESP-IDF v6.1의 include 순서는 패키지 측에서 수정: 메인 저장소 제안 종료, esp-idf 패키지 제안 병합 (10-26)
    1. 툴체인 및 개발 경험
      • vscode-rt-smart 0.4.14 병합: 4826줄 제거, 확장이 IDE에서 Env 진입점으로 회귀 (10-26)
      • Eclipse 프로젝트 생성기 커널 매크로 누락: Studio의 24개 암시적 선언 경고에 해법 제시 (10-26)
    1. 생태계 및 벤더 적용
      • Renesas RA6W1 시스템 리소스 할당 최적화 제출, BSP 2단계 개선 진입 (10-26)
      • STM32 이더넷 ops 계층 및 SR8201F PHY 추가, ADC 로그 레벨 하향 (10-26)
    1. 공식 및 커뮤니티
      • 공식 뉴스 인터페이스 24시간 신규 없음, 최신 호는 6월 17일에서 정지 (10-26)
      • 커뮤니티 장문 《rtthread 시작 링크 분석》: Reset_Handler부터 main까지 세 단계로 분해 (10-26)
      • 미디어 측 24시간 신규 기사 없음, 최근 것은 여전히 10-24의 RISC-V 서밋 보도 (10-26)
    1. 요약 및 트렌드 관찰
      • 이번 호 트렌드: 병합 정체, 결함 보고와 툴체인 개조가 바통을 이어받음
      • 한계 및 중복 제거 설명

1. 커널 및 버전 동향

1.1 메인라인 24시간 커밋 없음, 마지막 커밋은 여전히 lwIP 루프백, 조직 내에서는 VS Code 확장만 움직임 (10-26)

날짜: 2026-10-26 (확인 시간)　출처: 메인 저장소 커밋 기록, 조직 저장소 목록

이번 기간 master에는 어떤 커밋도 올라가지 않았다. 메인 저장소의 마지막 커밋은 여전히 10-25 19:26의 lwIP 루프백 netdev(#11893)이며, 그 이전은 10-23의 clang-format 규칙 마무리(#11859)로, 두 건 모두 지난 호 리포트에서 다룬 바 있다. 다시 말해 10-26 하루 동안 메인라인 코드는 전진하지 않았고, 신규 병합도, master에 직접 푸시된 유지보수 커밋도 없었다.

조직 차원에서도 조용하기는 마찬가지였다. 35개 저장소 중 최근 7일 내 푸시가 있는 곳은 6개뿐이며, 24시간 기간에 해당하는 곳은 vscode-rt-smart(10-26 22:35의 병합 커밋) 한 곳뿐이다. sdk와 toolchains-ci의 최근 동작은 10-26 07:57과 00:33에 멈춰 있어 모두 기간 시작점 이전이며, 내용은 지난 호에서 다룬 TriCore 툴체인과 QEMU 에뮬레이터 두 패키지다. packages와 pkgs-test의 마지막 커밋은 여전히 10-23이다.

버전 측면에는 변화가 없다. 최신 릴리스와 태그는 여전히 09-10의 v5.3.0이며, 프리릴리스도, 새 태그도 없다.

1.2 병합 대기열 13개 제안 같은 날 갱신, 신규는 Renesas RA6W1 한 건뿐 (10-26)

날짜: 2026-10-26 (최종 갱신)　출처: 메인 저장소 제안 목록

24시간 이내에 총 13개의 제안에 새로운 움직임이 있었으며, 그중 12건은 여전히 심사 중이고 1건은 종료되었으며, 병합된 건은 한 건도 없습니다. 가장 최근 병합은 여전히 10-25의 #11893입니다. 구성은 비교적 집중되어 있습니다. 수정류 6건(tmpfs 잘림 #11910, dlmodule 미초기화 전역 변수 #11915, 시리얼 rx_indicate #11931, settimeofday #11928, gmtime_r #11929, NVMe 네임스페이스 누수 #11920), BSP 및 드라이버 3건(ESP32-S3 #11844, RA6W1 #11934, STM32 이더넷 #11819), 도구류 3건(Eclipse 내보내기 #11930, mkdist #11874, Keil/IAR 타깃 선택 #11743)이며, 종료된 건은 #11926입니다(2.4 참조).

당일 새로 열린 것은 #11934 한 건뿐입니다. 수정류가 절반을 넘는다는 것은 리뷰 측이 여전히 진행 중이며 다만 병합으로 이어지지 않았을 뿐임을 보여줍니다. 검색 결과에는 2018년과 2019년의 오래된 제안 두 건(#1956, #2461)이 인덱스 갱신으로 업데이트 목록에 나타났으나 통계에는 포함하지 않습니다.

2. 보안 및 안정성 후속

2.1 signalfd의 전역 카운터 범위 초과: 11번째 호출부터 커널 포인터를 힙 블록 밖에 기록 (10-26)

날짜: 2026-10-26 16:13(생성 시간)　출처: Issue #11933

이번 호에서 가장 비중 있는 항목입니다. 연구자는 components/libc/posix/io/signalfd/signalfd.c에서 파일 스코프 전역 카운터 is_head_init로 각 파일 디스크립터 전용 배열 sfd->lwp[10]을 인덱싱하는데, signalfd_add_notify()는 사용 전에 아무런 경계 검사도 하지 않는다고 지적했습니다. signalfd_close()는 이 카운터를 되돌리지 않으므로 오직 증가만 합니다. 새 컨텍스트를 만들 때는 lwp[0 .. is_head_init-1]만 0으로 초기화하므로, 같은 프로세스에서 다시 생성할 때는 결코 자신과 매칭되지 않아 반드시 쓰기 분기를 타게 됩니다.

결과는 매우 구체적으로 기술되어 있습니다. lwp[]는 struct rt_signalfd_ctx의 마지막 멤버이며, 전체 구조체는 arm32에서 1536바이트이고 배열은 정확히 힙 블록 끝에 위치합니다. 11번째로 signalfd(-1, ...)를 호출할 때 쓰기는 할당 블록 밖 첫 번째 워드, 즉 소형 메모리 할당자의 다음 블록 헤더에 떨어집니다. 이후 생성할 때마다 4바이트씩(64비트에서는 8바이트 스텝) 더 바깥으로 밀려나, 호출자가 리듬을 제어하는 지속적인 커널 힙 범위 초과 쓰기가 형성되며, 기록되는 값마저 커널 포인터입니다.

영향 범위는 작성자가 레이블별로 하나하나 확인했습니다. 도입 지점은 2023-09-11의 7c3d966d(#8001)이며, v5.0.2 / v5.1.0 / v5.2.0 / v5.2.1 / v5.2.2 / v5.3.0과 현재 master(5d1fb66d)가 모두 해당됩니다. 트리거 전제는 RT_USING_SMART=y뿐입니다. RT_USING_POSIX_SIGNALFD는 이 설정에서 기본값이 y이며, 두 공식 QEMU Smart BSP의 설정도 모두 켜져 있으므로 기본 RT-Smart 빌드로도 트리거될 수 있습니다. 재현에는 bsp/qemu-vexpress-a9(Cortex-A9, 32비트, FAT sd 카드 루트 파일시스템)를 사용하며, PoC는 /sbin/init으로 설치합니다.

현재 이 이슈에는 대응 수정 제안이 없고 레이블도 지정되지 않았습니다.

2.2 동시 종료 상황에서 musl 스레드 연결 리스트의 해제 후 사용: futex 락이 상호 배제 역할을 하지 못함 (10-26)

날짜: 2026-10-26 11:22(생성 시간)　출처: Issue #11932

두 번째 결함 보고는 다른 보고자로부터 왔으며, 환경은 RT-Thread 5.2.2의 RT-Smart, SMP, aarch64, musl 1.2.5입니다. 현상은 동시 pthread_create와 pthread_exit 시 사용자 프로세스가 크래시되며, 크래시 지점은 musl_pthread_exit입니다. 연결 리스트 제거 시 기록하는 스레드 디스크립터가 이미 해제되었거나 언매핑되어 있거나(Data Abort), 스레드의 반환 주소가 0으로 덮어써진 경우(Instruction Abort)입니다.

작성자의 진단 결론은 문제가 완전히 사용자 공간에 있다는 것입니다. musl은 futex 기반 __tl_lock / __tl_sync로 스레드 연결 리스트를 보호하지만, SMP 동시 종료 시나리오에서는 이 락 그룹이 실제로 상호 배제를 제공하지 못해 이중 연결 리스트가 깨집니다. 커널 측 futex 구현 자체는 의미론적으로 올바르며 이 결함을 부담하지 않습니다. 재현 자료는 1000회, 8스레드의 tl_race 프로그램이며 수백 회 내에 크래시가 발생합니다.

이 이슈에는 bug, Arch: ARM/AArch64, RT-Smart 세 개의 레이블이 붙어 있고 전체 분석 문서가 첨부되어 있습니다. 2.1과 마찬가지로 RT-Smart 계열에 속하지만 계층이 다릅니다. 2.1은 커널 힙이고, 이 항목은 사용자 공간 libc입니다.

2.3 시간 하위 시스템의 두 가지 수정이 성숙 버전으로 전환: settimeofday 강제 변환 제거, gmtime_r 음수 타임스탬프 처리 (10-26)

날짜: 2026-10-26 14:17 및 17:48 (최종 업데이트)　출처: PR #11928, PR #11929

지난 회차에 기록한 시간 서브시스템의 네 건 중, 대응되는 두 건의 수정이 이번 모니터링 기간에 한 단계 진전되었으며, 모두 “성숙 버전, 머지 가능”으로 체크되었다.

#11928은 파일 하나만 수정하며 +185/-135: settimeofday()는 원래 (long)으로 tv_sec을 강제 형변환한 뒤 부호를 판단했는데, ILP32이면서 time_t가 64비트이고 long이 32비트인 구성에서는 2^31부터 2^32-1 사이의 합법적인 타임스탬프가 음수로 잘려나가, 함수가 RTC 장치를 건드리기도 전에 EINVAL로 거부했다——2208988800(2040-01-01)이 바로 그렇게 거부된 사례다. 수정 방식은 필드 자체의 타입에 따라 검증하고 강제 형변환을 하지 않는 것이다.

#11929는 두 파일 +104/-9: gmtime_r()은 C의 나눗셈과 나머지 연산으로 타임스탬프를 분해하는데, C의 나눗셈은 0 방향으로 절삭되므로 음수 입력에서는 나머지가 음수가 되고, 연도 루프는 미래 방향으로만 진행할 수 있어 -1은 1970-01-01 00:00:-1이 되고, -31536000의 연도 필드는 1970-01--364가 되었다. 수정 방식은 음수 경로를 정규화한 뒤 분해하는 것이다.

두 건 모두 머지되지 않았다. 나머지 두 건(timer_gettime() 절삭 #11924, 시간 서브시스템 작업 항목 모니터링 #11927)은 이번 모니터링 기간에 새로운 진전이 없다.

2.4 ESP-IDF v6.1의 include 순서를 패키지 측에서 수정: 메인 저장소 제안 종료, esp-idf 패키지 제안 머지 (10-26)

날짜: 2026-10-26 09:15 및 11:37 (머지 및 종료 시각)　출처: RT-Thread-packages/esp-idf 제안 #19, 메인 저장소 제안 #11926

지난 회차에 기록한 #11926은 ESP32 C3/C6의 FreeRTOS 헤더 파일 포함 순서를 메인 저장소에서 조정하여 ESP-IDF v6.1 적응 후 master에서의 빌드 실패를 해결하려 했다. 이번 논의에서 다른 경로가 제시되었다: 메인테이너가 댓글에서 “AI로 idf를 scons로 바꾸게 하자”고 제안하며 패키지 저장소의 제안 #19를 지목했고, 다른 메인테이너가 이어서 패키지 저장소 건을 먼저 머지해야 하는지 되물었다.

결과적으로 패키지 저장소 제안 #19(fix(scons): prioritize RT-Thread FreeRTOS headers)는 10-26 09:15에 머지되었고, 메인 저장소 #11926은 11:37에 종료되어 머지되지 않았다. 즉, 헤더 파일 우선순위 문제는 SCons 빌드 스크립트 계층에서 해결되었으며, 메인 저장소는 더 이상 include 순서를 수정하지 않는다. 이 점이 BSP 메인테이너에게 주는 의미는: esp-idf 관련 빌드 문제는 앞으로 패키지 저장소에서 우선 처리하고, 메인 저장소는 커널과 프레임워크 측 변경만 담당한다는 것이다.

3. 툴체인과 개발 경험

3.1 vscode-rt-smart 0.4.14 머지: 4826줄 제거, 확장이 IDE에서 Env 진입점으로 축소 (10-26)

날짜: 2026-10-26 22:35 (머지 시각)　출처: vscode-rt-smart 제안 #38

조직 내 당일 유일한 코드 작업은 메인테이너 본인이 제출하고 머지한 확장 다이어트였다. 49개 파일 +883/-4826, 버전 번호는 0.4.14로 올라갔으며, 산출된 vsix는 1,296,751바이트다.

삭제된 것이 추가된 것보다 훨씬 많다: Kconfig 뷰, SDK 관리자, 툴체인 설정, 심볼 분석(Symbolic Analysis) 네 가지 기능이 통째로 제거되었고, 이와 함께 ELF 및 DWARF 파서(elf-parser.ts, dwarf-parser.ts, handleElf.ts 합계 약 887줄)와 291줄의 설정 문서도 퇴장했다. RT-Thread Setting 뷰는 Env의 설치, 업데이트, 상태 표시만 수행하도록 축소되었으며, 프로젝트 루트 디렉터리 설정은 유지된다.

새로 추가된 것은 에디터 내장 브라우저 명령 하나와 code --open-url의 URI 처리이며, 기존 인증 콜백은 유지되었다. 이와 함께 140줄의 브라우저 테스트가 보강되었고, 작성자가 제시한 검증 기준은 npm run compile, npm run lint, npm test(13건 통과), npm run package:vs 네 단계다.

제품 포지셔닝 관점에서 보면 이는 명백한 후퇴다: 확장은 더 이상 VS Code 안에서 RT-Thread Studio의 설정 및 디버깅 능력을 재현하려 하지 않고, “Env 진입점 + 내장 브라우저” 두 가지만 유지하여 부피와 유지보수 면을 줄였다.

3.2 Eclipse 프로젝트 생성기가 커널 매크로를 누락: Studio의 24개 암시적 선언 경고에 해법 등장 (10-26)

날짜: 2026-10-26 23:33 (최종 업데이트)　출처: 메인 저장소 제안 #11930

지난 호에 수록된 커뮤니티 장문에서 “Studio 빌드 시 rt_sched_* 암시적 선언 경고 24건 발생”이 기록되었는데, 이번 회차에 대응 제안이 나왔다. 단일 파일 +151/-2로, 프로젝트 생성기 측에서 수정한다.

근본 원인은 명확히 기술되어 있다: include/rtsched.h의 스케줄러 인터페이스는 __RT_KERNEL_SOURCE__와 __RT_IPC_SOURCE__ 두 매크로로 보호되는데, gcc와 armclang 분기는 src/SConscript에서 LOCAL_CPPDEFINES를 통해 주입되어 명령줄 scons 빌드에서는 인식되지만, Studio가 매번 make 전에 호출하는 tools/targets/eclipse.py는 이 그룹 수준 정의를 수집하지 않아 dist로 내보낸 프로젝트에서 24건의 -Wimplicit-function-declaration이 발생한다: clock.c 1건, ipc.c 7건, thread.c 12건, timer.c 1건, scheduler_comm.c 3건.

수정 방식은 __RT_KERNEL_SOURCE__를 Kernel 그룹의 전역 CPPDEFINES로 승격하여 기존 msvc 분기와 일치시키는 것이다. 변경은 커널 소스 코드를 건드리지 않고 프로젝트 생성 스크립트만 수정한다.

4. 생태계와 벤더 적응

4.1 Renesas RA6W1 시스템 자원 할당 최적화 제출, BSP 2차 완성 단계 진입 (10-26)

날짜: 2026-10-26 18:22 (생성 시간)　출처: 메인 저장소 제안 #11934

이번 모니터링 기간에 유일하게 새로 열린 제안으로, Renesas RA6W1 방향의 정기 제출자로부터 왔으며 브랜치명은 rcitach/sboot, 5개 파일 +191/-110, 제목은 “시스템 자원 할당 최적화”이다.

RA6W1의 BSP는 “먼저 골격 병합, 이후 드라이버 보충”의 2단계 방식을 따른다: 첫 버전은 8월에 병합되었고, 이후 칩 원제조사 측에서 외부 장치와 전원 관리를 분할 보충한다. 이번 건은 2단계에 해당하며, 부팅과 자원 할당 관련 설정을 변경하고 외부 장치 드라이버 프레임워크는 변경하지 않는다. 제안 템플릿의 검증 BSP와 .config 두 항목은 아직 작성되지 않았으며, 상태는 여전히 초안 기준이다.

4.2 STM32 이더넷 ops 계층과 SR8201F PHY 추가, ADC 로그 레벨 하향 (10-26)

날짜: 2026-10-26 10:25 (최종 업데이트)　출처: 메인 저장소 제안 #11819

세 가지를 하나로 묶은 드라이버 제안으로, 4개 파일 +34/-3, STM32 측 세 가지 독립 문제를 다룬다.

첫째, ADC 드라이버의 기본 로그 레벨이 너무 높아 정상 사용 시 화면이 넘치므로 DBG_WARNING으로 변경하고 매크로 스위치를 유지한다. 둘째, ETH 드라이버에 ops 계층 적응이 없어 상위 네트워크 프레임워크가 통일된 인터페이스로 장치를 조작할 수 없었는데, 이번 건에서 ops 콜백 집합을 구현하고 등록했다. 셋째, PHY 드라이버가 SR8201F를 지원하지 않아 해당 칩을 사용하는 보드에서 이더넷을 시작할 수 없었는데, 이번 건에서 식별 ID, 초기화 흐름과 레지스터 설정을 보충하고 PHY 목록에 추가했다. 검증 보드는 stm32f429-atk-apollo이며, 설정에서 RT_USING_DEVICE_OPS, BSP_USING_ETH, PHY_USING_SR8201F를 활성화했다.

5. 공식과 커뮤니티

5.1 공식 뉴스 인터페이스 24시간 신규 없음, 최신 회차는 6월 17일에 정체 (10-26)

날짜: 2026-10-26 (확인 시간)　출처: 공식 뉴스 인터페이스

조직 분류의 뉴스 목록은 여전히 5건을 반환하며, updatetime은 각각 2026-06-17(2건), 06-11, 06-09, 06-02로, 아부다비 투자 포럼, 제4회 소프트웨어 혁신 발전 대회, 린강 “디수이즈후이” 임바디드 인텔리전스 행사, 장장하이커 실험 초등학교의 교외 기지 지정 수여와 제5회 산업 기술 포럼을 포함한다. 5건 모두 이전 회차 내용이며, 이번 모니터링 기간에는 업데이트가 없다.

인터페이스가 반환하는 필드에는 발표 날짜가 없고 updatetime만 있으며, 본문의 이벤트 시간은 updatetime보다 이르다(예를 들어 아부다비 포럼 본문은 6월 11일, 산업 기술 포럼은 5월 27일로 표기). 인용 시 본문 이벤트 시간을 기준으로 한다.

5.2 커뮤니티 장문 “rtthread 시작 링크 분석”: Reset_Handler에서 main까지 세 단계로 분해 (10-26)

날짜: 2026-10-26 08:59 (게시)　출처: 커뮤니티 글: rtthread 시작 링크 분석

커뮤니티 기사 인터페이스에는 모니터링 기간 내에 이 한 편만 새로 추가되었으며, 약 5700자 분량이다. 저자는 자신의 환경이 STM32F103C8T6 + RT-Thread 4.0.3 + RT-Thread Studio 2.3.1(GCC)라고 밝히고, 글의 코드는 매뉴얼을 그대로 옮긴 것이 아니라 본 프로젝트의 실제 빌드에서 가져온 것이라고 명시했다.

체인은 세 단계로 나뉜다. 첫 단계는 어셈블리로, Reset_Handler가 .data 초기값을 Flash에서 SRAM으로 옮기고, .bss를 0으로 초기화하고, SystemInit을 호출하고, entry로 점프한다. 저자는 여기서 흔한 오해 하나를 짚는데, SystemInit은 메인 주파수를 72MHz로 설정하지 않으며 단지 RCC를 리셋 상태로 되돌리고 SCB->VTOR를 Flash 시작 주소로 설정할 뿐이다. 두 번째 단계는 C 초기화로, entry가 rtthread_startup()에 진입하고, rt_hw_board_init()에서야 72MHz 클럭과 힙을 설정하며, 이어서 main, timer, idle 세 스레드를 생성한다. 세 번째 단계는 스케줄러 시작으로, rt_system_scheduler_start()가 우선순위가 가장 높은 준비 상태 스레드를 고르며, 기본적으로 timer 스레드가 먼저 실행되고, main()은 main_thread_entry() 안에서 rt_components_init() 이후에야 등장한다.

글 끝에는 네 가지 ‘자주 헷갈리는 점’과 자가 검증 방법 한 절도 덧붙였는데, 커널 코드를 읽을 때 흔히 겪는 혼동점을 정리한 것이다.

5.3 미디어 측 24시간 신규 기사 없음, 최근 것은 여전히 10-24 RISC-V 정상회의 보도(10-26)

날짜: 2026-10-26(확인 시각)　출처: Google News 집계(중국어)

중영문 여섯 개 쿼리(정확 문자열 3일, RuiyAI 7일, Ruiqing 7일, 영문 정확 문자열 3일, RTOS 3일, 운영체제 3일)는 오래된 기사 두 편만 돌려주었다. 10-24 EE Times China의 “단말 AI, RISC-V 새 전장으로: RT-Thread RuiyAI 풀스택 실천, 제6회 RISC-V 중국 정상회의에서 공개”와 10-21의 “Ruiqing 플랫폼 V1.8.4 릴리스, 인코더·MIPI·GPIO 전면 업그레이드”이다. 두 편은 각각 10-26과 그 이전 리포트에 이미 수록되었으며, 이 모니터링 기간에는 신규 건이 없다.

영문 측 세 쿼리는 모두 적중이 0이었다. HN Algolia의 19건 과거 적중 중 최신은 2025-05에 멈춰 있고, 모니터링 기간 내 네 개 후보는 모두 “threads” 글자 그대로의 오매칭(Python 스레드 디버깅 도구, 가상 스레드 프로파일링, Threads 소셜 플랫폼 MCP)이어서 전부 제외했다.

6. 요약 및 트렌드 관찰

6.1 이번 트렌드: 병합 정체, 결함 보고와 도구체인 개조가 이어받음(10-26)

날짜: 2026-10-26(이번 기간)　출처: 메인 저장소 커밋 기록

네 갈래로 오늘을 요약할 수 있다.

첫째, 코드 메인라인이 정체되었다. 24시간 커밋 0건, 병합 0건이며 13개 제안이 큐 안에서 움직였으나 단 한 건도 반영되지 않았다. 지난 기간의 72시간 모니터링 기간에서도 두 건만 반영되었으니, 오늘의 커밋 0건은 같은 리듬의 연장이다. 개발 측은 리뷰를 기다리고, 리뷰 측은 수정 완성을 기다리는 중이다.

둘째, 보안 면은 계속 외부 연구자에 의해 주도된다. 10-24는 시간 하위시스템 네 건이었고, 오늘은 RT-Smart의 두 건으로 바뀌었다. signalfd의 전역 카운트 범위 초과(커널 힙 임의 쓰기, v5.0.2 이후 모든 버전 해당, 기본 설정으로 트리거 가능)와 musl 스레드 연결 리스트의 동시 해제 후 사용이다. 두 건 모두 특수 하드웨어가 필요 없고 QEMU로 재현 가능하며, 모두 ‘기본 설정하의 Smart 빌드’라는 층을 가리킨다.

셋째, 도구체인 측은 유지보수자 본인이 직접 나섰다. vscode-rt-smart는 한 번에 4826줄을 걷어내고, 확장을 ‘크고 전부 갖춘 IDE 대체물’에서 Env 진입점과 편집기 내 브라우저로 축소했다. 동시에 Eclipse 내보내기에서 커널 매크로를 누락하는 문제에도 패치를 제출했으며, Studio 하의 24건 암묵적 선언 경고를 직접 겨냥했다.

넷째, 벤더 측은 여전히 BSP가 주류다. Renesas RA6W1은 2기 리소스 할당 최적화에 들어갔고, ST는 이더넷 ops와 SR8201F PHY를 보완했으며, Espressif의 ESP32-S3 BSP 제안은 여전히 55개 파일 규모로 리뷰를 기다리고 있다. 칩 신제품이나 아키텍처급 움직임은 없다.

6.2 한계와 중복 제거 설명

날짜: 2026-10-27(이번 기간)　출처: 메인 저장소 커밋 기록

첫째, 공식 뉴스 인터페이스와 커뮤니티 기사 인터페이스를 모두 확인했으며, 전자는 6월 이후 업데이트가 없어 이번 기간 공식 채널에는 새 내용이 없다.

둘째, 이번 기간은 10-26 기간과 겹치지 않는다. 지난 기간의 모니터링 종료 시점은 10-26 08:00이고, 이번 기간은 그 시점부터 계산한다. #11910, #11915, #11920, #11901 등의 제안은 지난 기간에 이미 ‘병합 대기 결함’으로 정리되었으므로, 이번 기간에는 다시 펼치지 않고 큐 통계에만 등장한다.

셋째, #2461, #1956, #2467, #5096 네 건의 오래된 제안은 수록하지 않았다. 검색 결과에서 이들의 업데이트 시각이 이번 모니터링 기간에 걸려 있으나, 종료 및 병합 시각은 각각 2019, 2018, 2019, 2021년으로, 인덱스 갱신에 해당할 뿐 새로운 사건이 아니다.

넷째, GitHub 익명 인터페이스 한도가 이번 회차에서 상한에 근접하여, 조직 수준 검증은 단일 sort=pushed 요청으로 완료했으며 저장소별로 전체 이벤트를 가져오지 않았습니다. 메인 저장소 커밋은 commits 인터페이스가 반환한 처음 100건을 기준으로 했으며, 이는 24시간 모니터링 기간을 충분히 커버합니다.

부록: 출처 검증표

출처 검증 결과
RT-Thread 공식 뉴스 인터페이스(조직 분류) 신규 없음, 여전히 5건 반환, 최신 updatetime은 06-17에 멈춤
커뮤니티 글 인터페이스(article) 모니터링 기간 내 1편 신규: rtthread 시작 링크 분석(10-26 08:59)
GitHub 메인 저장소 commits 모니터링 기간 내 0건, 마지막 건은 10-25 19:26의 lwIP 루프백
GitHub 메인 저장소 PR 13건 업데이트, 0건 머지, 1건 신규 오픈(#11934), 1건 클로즈(#11926)
GitHub 메인 저장소 Issue 2건 신규 오픈: #11933 signalfd 경계 초과, #11932 musl 스레드 연결 리스트 UAF
GitHub 메인 저장소 releases / tags 신규 릴리스 없음, 최신은 여전히 09-10의 v5.3.0
GitHub org 저장소 푸시 35개 저장소 중 최근 7일간 6개 저장소에 푸시, 24시간 모니터링 기간 내에는 vscode-rt-smart만
GitHub RT-Thread/sdk 모니터링 기간 내 동작 없음(최근 10-26 07:57, TriCore 두 패키지, 지난 회차에 이미 수록)
GitHub RT-Thread/packages 모니터링 기간 내 동작 없음(마지막 커밋 10-23)
GitHub RT-Thread-packages/esp-idf 1건 머지: #19 헤더 파일 우선순위 수정
GitHub RT-Thread/pkgs-test 모니터링 기간 내 동작 없음(마지막 커밋 10-23)
GitHub topic:rt-thread 2개 저장소 푸시(AKP05E 펌웨어, AWTK), 모두 생태계 참고용으로 미수록
Google News 집계(중영문, 프록시 경유) 6개 쿼리, 중국어 2건 모두 기존 기사, 영어 0건
HN Algolia 4개 후보 모두 threads 문자열 오매칭으로 제외
업계 매체(EET-China 칼럼) 모니터링 기간 내 신규 기사 없음, 최근 1편은 10-24 서밋 보도

전체 출처 목록

com/RT-Thread/rt-thread/pull/11743>