Linux 7.1

 (lore.kernel.org)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Linux 7.1은 정규 릴리스 시점에 맞춰 배포됐으며, 릴리스 직후 병합 창이 열리는 커널 개발 흐름이 이어짐
  • 이번 릴리스의 지난주 변경 내역에는 특별히 흥미롭거나 우려할 만한 항목이 두드러지지 않았으며, 이는 의도한 상태에 가까움
  • 변경 사항은 주로 GPU·네트워킹·사운드·기타 드라이버의 작은 업데이트와 네트워킹 및 추적 도구 수정으로 구성됨
  • 병합 창은 다음 날 열리지만, 노트북과 인터넷이 없는 장거리 비행 때문에 초기 며칠의 처리 시간이 평소보다 불규칙할 수 있음
  • 일부 초기 pull request는 미리 가져와 오프라인에서도 처리할 수 있으며, 릴리스 이후에도 테스트를 계속해야 함

릴리스 개요

  • Linux 7.1 릴리스가 정규 시점에 맞춰 진행됐지만, 현재 위치의 시간대가 평소와 달라 정규 시간대에서의 릴리스는 아님
  • 병합 창은 릴리스 다음 날 열리며, 그 시점에는 또 다른 시간대에 있게 되어 일정이 다소 불규칙해질 수 있음
  • 평소에는 병합 창 초반 며칠에 가능한 많은 작업을 앞당겨 처리하지만, 이번에는 노트북과 인터넷 없는 장거리 비행 때문에 같은 방식이 어려울 수 있음
  • 일부 초기 pull request는 미리 가져와 둔 상태라 오프라인에서도 일부 병합 작업을 처리할 수 있음

병합 창 운영

  • 병합 창에서 약간의 지연이 생길 수 있지만, 이번 릴리스의 핵심 소식은 7.1 배포임
  • 릴리스를 한 주 연장하는 방안도 검토됐지만, 그럴 가치가 크지 않다고 판단해 진행하지 않음
  • 향후 며칠 동안 병합 창 응답 시간이 다소 무작위적일 수 있어 사전 양해가 필요함
  • 릴리스 이후에도 테스트는 계속되어야 함

지난주 변경 내역의 성격

  • 지난주 shortlog에는 특별히 흥미롭거나 무서운 항목이 두드러지지 않으며, 이는 정상적인 릴리스 상태에 해당함
  • 변경 사항 대부분은 작은 드라이버 업데이트로 구성됨
    • 대상 영역은 GPU, 네트워킹, 사운드, 기타 드라이버임
  • 네트워킹과 trace tooling 관련 수정도 포함됨
  • 그 밖의 영역에는 임의의 작은 변경들이 있음

주요 수정 범위

  • USB 직렬 드라이버에서는 heap overflow와 bulk-out buffer overflow 문제가 수정됨
  • 네트워킹 영역에서는 Open vSwitch, netfilter, SCTP, TCP, IPv6, XDP, RDMA, mlx5, mvpp2 등 여러 하위 구성요소의 오류와 누수 문제가 수정됨
  • DRM과 GPU 영역에서는 amdgpu, xe, i915, virtio, hyperv, colorop 관련 오류와 refcount 문제, suspend·shutdown 관련 문제가 수정됨
  • 메모리 관리와 파일·IPC 주변 영역에서는 use-after-free, NULL pointer dereference, refcount leak, resource leak 등이 다수 수정됨
  • I2C, GPIO, SPI, ASoC, cpufreq, firmware, thunderbolt, Hyper-V 관련 드라이버와 도구에도 작은 수정이 반영됨

실무적 참고점

  • 이번 릴리스는 큰 기능 발표보다 안정화 성격의 수정 릴리스에 가까운 변경 흐름을 보임
  • 드라이버, 네트워킹, 추적 도구를 사용하는 환경에서는 shortlog에 포함된 하위 시스템별 수정 항목을 확인할 필요가 있음
  • 릴리스 직후에도 테스트 지속이 요청됐으며, 병합 창 초기 응답 지연 가능성을 감안해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 개인적으로는 ISP의 모뎀/라우터와 노트북 조합에서 겪던 느린 WiFi를 고치는 이 커밋이 꽤 기대됨
    https://github.com/torvalds/linux/commit/711a9c018ad252b2807...
    Fedora에 빨리 들어가면 좋겠음

  • 새 NTFS 드라이버를 써보는 게 기대됨
    이번 버전이 Paragon의 ntfs3보다 나았으면 함

    • 이전 드라이버에서 뭐가 부족했는지 궁금함
      Linux의 NTFS 지원은 대체로 Windows 디스크에서 파일을 읽고 쓰기 위한 것 아닌가 싶고, Paragon 이전의 FUSE 기반 드라이버까지 포함해 Linux NTFS 드라이버들은 그 용도로는 괜찮았다고 봄
    • 괜찮음
      내 Gentoo 오버레이에 패키징해서 몇 달째 쓰고 있는데, ntfs3에서 보던 이상한 문제들이 없음

  • Arch의 현재 기본값은 7.0.10임
    7.1이 곧 롤링으로 들어오길 기대 중

    • Fedora는 몇 달쯤 걸릴 것 같음
      지금은 7.0.12임

  • 아주 오래되고 거의 안 쓰이는 코드를 커널 밖으로 밀어내서 AI 보조 버그 리포트를 줄이는 건, AI가 가져온 최고의 결과 중 하나라고 봄
    마음에 듦
    이제 모든 것에서 군살을 좀 덜어내기 시작해야 함

    • 그런 사고방식 때문에, 멀쩡히 잘 작동하는 데스크톱들이 Windows 11을 못 돌린다는 이유로 조직들이 전부 새로 사게 됐던 것임
      나는 10년 된 서버도 아직 쓰고 있는데, Linux에서는 잘 돌아감
    • “완벽함은 더 이상 더할 것이 없을 때가 아니라, 더 이상 뺄 것이 없을 때 달성된다.” — Antoine de Saint-Exupéry
      내 친구 중 하나는 한동안 오늘 X줄의 코드를 지웠다는 사람으로 악명이 높았음
    • 몇몇 배포판에서 오래된 드라이버를 커널 빌드에서 빼는 코드를 제출해 봤지만 전부 거절당했음
      Torvalds가 괜찮다고 하기 전까지는 다들 사용자 환경을 깨는 것을 두려워함
    • 겉으로는 농담이겠지만, 처음 읽었을 때는 Linux가 거의 안 쓰이는 기능을 건드리는 공격 경로를 제거하는 것으로 이해했음
      적어도 휴대폰 운영체제에서는 특이하고 드문 형식이나 기능이 악용 가능한 버그의 흔한 출처였거나 지금도 그럴 수 있음
    • 최종 사용자는 업그레이드하지 않을 수도 있으니, 구식 하드웨어의 정의가 있으면 좋겠음
      내 기준으로는 모든 HP 프린터가 구식이지만, 다른 사람도 똑같이 타당하면서 전혀 다른 기준을 가질 수 있음
      컴퓨터 하드웨어에서는 이걸 어떻게 정하는지 궁금함

  • 이 릴리스에 특별히 흥미로운 게 있나?
    버전의 첫 번째 숫자는 두 번째 숫자가 너무 커졌을 때 바뀌는 것뿐이고, 다른 이유가 있는 건 아니라고 봄

  • 콘텐츠가 로드되기 직전에 애니메이션 아바타가 아주 잠깐 지나가는 걸 본 사람 있음? 그게 뭐였지?

  • 속보: Linus가 이동 중임
    내가 뭔가 놓친 건가, 아니면 그냥 또 하나의 숫자인가?

    • 숫자 변경이 별다른 변화를 주지 않고 한 번에 모든 걸 개선하려 들지 않으면 지루해지긴 함
      그래도 숫자에 대한 놓치기 싫은 심리가 새로움을 밀어주고, 그 덕분에 개선 루프가 더 촘촘해지는 건 장점임
      흥미롭고 위험한 것들은 항상 플래그 뒤에 있으니, 정말 신경 쓰이면 직접 커널과 시스템을 빌드하고 설정하고 벤치마크하면 됨
    • “아무튼 병합 창에서 약간의 딸꾹질이 있을 수는 있지만, 오늘의 소식은 7.1입니다.”
      “특별히 흥미롭거나 무서운 것은 눈에 띄지 않는데, 원래 그래야 합니다.”
      그러니까 숫자임
    • Linus에게 기내 WiFi 비용을 대줄 사람이 아무도 없다는 게 놀라움
      달러당 수익률로 보면 최고 수준의 지출일 텐데!

  • Debian Stable에서는 이걸 2036년쯤 볼 수 있다고 가정해도 안전한가?

    • 최신 Linux 커널 릴리스는 7.1, 7.0, 6.19, 6.18, … 순서임
      https://en.wikipedia.org/wiki/Linux_kernel_version_history
      7.0은 이미 forky(현재 testing)에 있고, trixie(현재 stable)용 백포트로도 제공됨
      https://packages.debian.org/search?keywords=linux-image-amd6...
      https://packages.debian.org/trixie-backports/linux-image-amd...
      trixie/stable의 기본 커널은 2024년 11월 처음 릴리스된 6.12이고, 업스트림에서 2028년 12월까지 공식 지원됨
    • 밈인 건 알지만, 나는 Debian Stable에서 백포트 커널을 쓰고 있고 버전은 6.19임
      현재 7.0과는 마이너 버전 하나 차이밖에 안 남
      더 많은 사람이 자기 기기에 Debian을 고려했으면 좋겠음. 매우 안정적인 시스템이라는 점이 마음에 들고, Ubuntu와 달리 정말 “그냥 작동하는” 경험이었으며 작은 배포판에서 생기는 마찰도 없었음
      Trixie가 아직 Testing이던 때 꽤 최신 기기에 Debian Trixie를 설치했는데, 호환성을 위해 전부 AMD로 맞추긴 했지만 필요한 드라이버가 모두 있었음
      이제 패키지 빌드 방법을 알아내서 Debian에 기여할 수만 있으면 좋겠고, AMD도 Linux용 NPU 지원을 제대로 정리해 주면 좋겠음
    • Debian에서는 바닐라 소스에서 직접 커널 패키지를 빌드하기가 꽤 쉬움
      나는 최신 7.0.x를 릴리스 후 몇 시간 안에 올려 쓰고 있음
      ChangeLog를 훑는 데 시간을 얼마나 쓰느냐에 따라 빌드는 30~45분 정도 걸림. 환경에 따라 다를 수 있음
    • 진지한 질문은 아니겠지만 그래도 진지하게 답하자면, Debian Stable에서 어떤 커널을 쓰는지 걱정한 적은 한 번도 없음
      더 최신 커널을 원하면 Debian unstable(Sid)을 쓰면 되고, 현재는 7.0.12임. 7.1이 mainline인 동안 현재 stable 커널에 해당함
      서버에서는 Stable, 현재 Trixie가 6.17.3 커널로도 충분히 잘 돌아감
      Debian Forky는 2027년쯤 릴리스될 것이고, 상황에 따라 7.0.x나 7.1.x 커널을 쓸 것임
      현재 testing, 즉 다음 stable이 될 릴리스에서 쓰는 커널은 7.0.10임
    • Forky/14가 내년에 릴리스될 때 이 버전이나 더 최신 버전을 포함하지 않을까?
      Debian은 느리게 움직이지만, 빠른 걸 원하면 Arch나 Fedora를 쓰면 되고, 그래도 Debian은 계속 움직임
답변달기