황현석 일지

회고. 저번 글에서는 Kite의 uninstall.sh를 꽤 자세히 다뤘습니다. 설치된 리소스를 지우는 것뿐 아니라, Longhorn webhook, namespace finalizer, host sshd 복원 worker처럼 서버에 남은 흔적을 어디까지 책임져야 하는지에 가까운 이야기였습니다. 그 글을 쓰면서 "내가 설치한 것들은 모두 깔끔하게 정리하자."는 쪽으로 생각이 많이 갔습니다. 그런데 이번에는 조금 반대 방향의 질문이 생겼습니다. 다녀간 자리를 잘 치우는 것도 중요하지만, 애초에 어디까지 들어가도 되는가를 먼저 정해야 하는 것 아닌가 싶었습니다. 처음에는 Kite를 설치하는 경험을 굉장히 좋게 하고 싶었습니다. 사용자가 README에 있는 명령을 복사해서 install.sh | bash로 실..

회고. 저번 글에서는 Kite의 E2E 테스트를 잡으면서 SSH gateway와 host sshd가 어떤 식으로 이어져야 하는지 정리했습니다. gateway가 22번 포트를 맡고, 기존 host sshd는 다른 포트로 이동하고, VM 계정이 아니면 다시 host sshd로 fallback되는 흐름을 실제 서버에서 확인한 이야기였습니다. 이번 글은 그 다음 단계의 회고입니다. stage에서 E2E가 통과했고, main에 push한 뒤 GHCR image build도 끝났습니다. 그런데 실제 사용자가 보게 될 README의 원격 uninstall.sh, ghcr-install.sh 흐름으로 기존 설치를 지우고 다시 설치해보니, stage E2E에서는 보이지 않던 Longhorn과 host sshd 경계 문제..

Shell Lab 글을 마무리하면서 마지막에 syscall 이야기를 조금 붙였습니다. 처음에는 그냥 fork(), waitpid(), kill() 같은 함수들이 어떻게 커널까지 들어가는지 정리하면 끝이라고 생각했습니다. 그런데 syscall을 정리하다 보니, 새로운 공부를 할 수 있었습니다.POSIX 기준으로 signal handler 안에서 printf를 호출하는 건 안전한 패턴이라고 말하기 어렵다. Shell Lab에서는 sigchld_handler 안에서 printf를 호출하는 식으로 구현했습니다. trace 출력 형식도 맞춰야 했고, 과제 풀이 문맥에서는 그렇게 작성한 코드가 흔합니다. 하지만 그것들은 사실 안티패턴이었습니다. 그리고 문득 궁금해진것은데, printf 가 고작 뭐길래 위험하다는 것..

저는 보통 저작권이 교수님한테 저당잡혀 있는 학교 과제에 대하여 글을 작성하지 않습니다. 과제중에 유일하게 포스팅을 하고 싶었던 주제는 Shell Lab입니다. 다행히, 이미 Shell Lab은 블로그에 글들이 널린 공공재입니다. 학교 과제를 하면서 Shell Lab이 가장 재미있엇습니다. 우선은 코딩이고, 저같은 레벨의 학부생 수준에서는 Low-Level에서 개발할 일이 별로 없어, 더더욱 재미를 느꼇던 것 같습니다. 미루고 미루다가, 거의 10개월이 지난 지금 포스팅을 합니다. 과제를 다시 읽어보게 되서 설렜습니다. Shell Lab은 처음 보면 진입장벽이 높아보입니다. 실제로 Shell Lab은 그 수업을 듣는 학생들의 문맥에서는 요구하는 배경지식이 많은 과제입니다. C 기본 문법만 어느 정도 아는..

회고.이전 글에서는 HWJ에서 C++ WASM runner를 붙이며 겪은 I/O 병목, WASI 전환, 표준 checker fast path 같은 이야기를 정리했습니다. 그때의 결론은 꽤 단순했습니다. 브라우저 안에서 채점을 하려면 모든 것을 WASM으로 밀어 넣는 것이 정답이 아니라, WASM이 필요한 곳과 JavaScript에서 바로 끝내야 하는 곳을 구분해야 한다는 것이었습니다. 이번에는 JavaScript 제출에 대한 고민입니다. 처음부터 지금 구조를 정답으로 잡은 것은 아니었습니다. 출발점은 훨씬 단순했습니다. 브라우저 native V8 JIT로 사용자 JS를 실행하면 빠릅니다. 그런데 온라인 저지처럼 “이 제출이 메모리 제한을 넘었는가?”를 판정하려고 하니, 갑자기 문제가 흐릿해졌습니다. 그래..

회고.안녕하세요. 최근에는 알고리즘 블로그 글을 조금 더 전문적으로 포스팅하고 싶다는 생각이 들었습니다. 단순히 풀이를 적고 끝내는 것이 아니라, 글 안에서 바로 코드를 실행하고 결과를 확인할 수 있으면 좋겠다고 생각했습니다. 그래서 Judge 기능이 달린 Blog를 만들자는 간단한 프로젝트를 진행하고 있었습니다. 프로젝트 명은 HWJ입니다. HWJ는 Hybrid WASM Judge의 줄임말입니다. 지금 만들고 있는 것은 기존 온라인 저지처럼 서버가 모든 테스트를 실행하는 구조가 아니라, 사용자의 브라우저 안에서 Web Worker와 WebAssembly를 이용해 테스트 생성, 정답 실행, 제출 코드 실행, 출력 비교를 위임하는 구조를 만들고 있습니다. 사용자의 어뷰징은 관심이 없습니다. 물론 실제 서비..