
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, and data engineering — plus mindset essays on confidence, routines, health, and sport psychology.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Wed, 19 Aug 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/syscall/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/linux/2026-08-19-kernel-reading-a-syscall-end-to-end</guid>
    <title>시스템 콜 하나를 끝까지 따라가기 — read가 커널 안에서 지나는 길</title>
    <link>https://www.youngju.dev/blog/linux/2026-08-19-kernel-reading-a-syscall-end-to-end</link>
    <description>커널이 읽을 수 있는 코드라는 것을 확인하는 가장 좋은 방법은 시스템 콜 하나를 처음부터 끝까지 따라가 보는 것입니다. read(2)를 골라 사용자 공간의 호출부터 커널 안의 실제 구현, 그리고 반환까지 실제 파일 경로와 함수 이름과 함께 추적합니다. x86_64에서 인자가 어느 레지스터에 실려 오는지, do_syscall_64가 번호를 어떻게 함수로 바꾸는지, SYSCALL_DEFINE3 매크로가 실제로 어떤 함수 셋을 만들어 내며 그래서 왜 sys_read를 grep해도 나오지 않는지를 매크로 정의를 펼쳐 보여 줍니다. 이어서 fs/read_write.c의 ksys_read와 vfs_read를 한 줄씩 읽으며 파일 디스크립터가 struct file이 되는 과정, 파일 오프셋이 다뤄지는 방식, 함수 포인터 테이블로 파일시스템별 구현이 선택되는 지점을 확인합니다. 마지막으로 커널이 왜 사용자 포인터를 그냥 역참조하지 않는지, 그리고 반환값이 왜 음수 errno인지를 다룹니다.</description>
    <pubDate>Wed, 19 Aug 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>linux</category><category>kernel</category><category>syscall</category><category>vfs</category><category>x86</category><category>kernel-source</category><category>c</category>
  </item>

    </channel>
  </rss>
