나머지 시스템은 그대로두고 Linux 커널 업데이트

저는 OpenBSD 사용자입니다. 에서 OpenBSD의 질문 은 말합니다 :

OpenBSD는 완전한 시스템으로 동기화 상태를 유지합니다. 서로 별도로 업그레이드 할 수있는 커널 플러스 유틸리티는 아닙니다.

시스템을 업그레이드 할 때 한 번에 업그레이드 할 수 있습니다. 커널과 기본 시스템이 교체됩니다. 그런 다음 타사 패키지를 업데이트합니다 . 경우 소스에서 컴파일 , 당신은 커널을 다시 컴파일하고 부팅합니다. 그런 다음 기본 시스템을 다시 빌드 한 다음 설치 한 패키지를 다시 빌드하십시오. 마지막으로 모든 것을 다시 빌드 한 후 몇 주 / 개월 이상 지난 경우에는 먼저 스냅 샷을 설치하고 다시 시작하십시오 (최신 CVS 지점을 따르는 경우).

동기화되지 않은 커널, 기본 시스템 및 / 또는 타사 패키지가 있으면 잠재적 인 문제의 원인이되며 공식 메일 링리스트에서 심각한 도움을받을 수 없습니다.

나는 이것으로 꽤 괜찮습니다. 사실 이것이 OpenBSD를 사용하는 이유 중 하나입니다. 그것은 시스템을 일관된 단위로 만들고 그것을 쉽게 정신적 개요를 형성 할 수있게합니다.

리눅스는 어떤가요? 내가 아는 대부분의 리눅스는 BSD와 같은 의미로 "기본 시스템"을 가지고 있지 않고 배포판 공급자가 모은 패키지 모음을 가지고있다. 그런 다음 시작부터 있던 것과 나중에 추가 된 것의 경계가 흐릿하게되도록 로컬 관리자가 추가 소프트웨어를 추가합니다.

리눅스 (일반적으로)와 사용자 공간 결합에 대한 강력한 커널이 없습니까? 커널은 다른 소프트웨어 패키지와 마찬가지로 내가 알고있는 한 업데이트되며 이것이 가능하다는 것을 약간 혼란스럽게합니다. 이것에 더하여 일부는 심지어 사용자 정의 커널 (OpenBSD에서는 권장되지 않음)을 컴파일하고 부트 메뉴에 다양한 커널 버전이 나열되어 있습니다.

Linux 시스템의 다양한 서브 시스템이 서로 독립적으로 업데이트 되더라도 서로 협력 할 수있는 사람은 누구입니까?

이 사이트의 다른 사용자가 요청 때문에 부탁 해요 이유는 저를 최신 버전으로 자신의 리눅스 시스템에서 커널을 교체 여부를 "행할 것이다". OpenBSD의 측면에서봤을 때 나는 이것이 시스템을 손상시키지 않을 것이라고 보장 할 수 없었습니다.

위의 "Linux"를 "Linux 배포", 커널 + 유틸리티의 약어로 사용합니다.

Linus Torvalds는 커널 변경에 대해 사용자 공간 회귀에 대해 매우 강한 의견을 가지고 있습니다 (자세한 내용은 " Linux 커널 : 사용자 공간 끊기 "질문 참조).

사용자 공간과 커널 사이의 인터페이스는 시스템 호출에 의해 제공됩니다. 최신 커널에는 더 많은 시스템 호출이있을 수 있으며 이러한 변경으로 인해 기존 응용 프로그램이 중단되지 않을 때 종료되는 변경이있을 수 있습니다. 시스템 호출 인터페이스에 플래그 매개 변수가있는 경우, 새로운 커널은 종종 새로운 비트 플래그로 새로운 기능을 노출합니다. 이런 식으로 커널은 이전 응용 프로그램과의 호환성을 유지합니다.

사용자 공간을 손상시키지 않고 기존 인터페이스를 변경할 수없는 경우 확장 된 기능을 제공하는 추가 시스템 호출이 추가되었습니다. 이것이 3 가지 버전 dup과 2 가지 버전의 umount시스템 호출 이있는 이유 입니다.

안정적인 사용자 공간을 갖는 정책은 커널 업데이트가 사용자 공간 응용 프로그램에서 거의 문제를 일으키지 않기 때문에 일반적으로 커널을 업그레이드 한 후에는 문제가 발생하지 않습니다.

그러나 커널 인터페이스 및 기타 구현 세부 사항에 대해 동일한 API 안정성이 보장되지는 않습니다 . sysfs를 (ON /sys) 및 procsfs은 (에 /proc/) 로우 레벨의 어플리케이션에 의해 사용되는 등 런타임 구성, 하드웨어, 네트워크 커널 프로세스를 구현 정보를 노출. 적절한 이유가 있다면 커널 버전간에 호환되지 않는 방식으로 인터페이스가 변경 될 수 있습니다. 변경 사항은 여전히 ​​가능한 경우 비 호환성을 최소화하려고 시도하며 응용 프로그램이 문제를 일으킬 가능성이 가장 적은 방식으로 인터페이스를 사용하는 방법에 대한 규칙 이 있습니다. 저수준이 아닌 응용 프로그램은 이러한 인터페이스를 사용하지 않아야하므로 영향도 제한됩니다.

@PeterCordes 는 procfs 또는 sysfs 의 변경으로 인해배포 초기화 스크립트에서 사용하는 응용 프로그램이 중단되면 문제가 발생할 수 있다고 지적했습니다.

배포판이 커널을 업데이트하는 방법 (장기 지원 또는 메인 라인)에 따라 다소 차이가 있으며 배포판이 업데이트 된 도구를 동시에 제공하기 때문에 문제는 비교적 드물다.

@StephenKitt 는 업그레이드 된 사용자 공간에는 최신 버전의 커널이 필요할 수 있으며,이 경우 시스템이 이전 커널로 부팅하지 못할 수 있으며 배포 릴리스 노트에서이를 언급 할 때 적절하다고 언급했습니다.

GNU 커널 프로젝트에 의해 개발 된 사용자 도구가 역사적으로 지배했던 Linux 커널과 Linux 배포판의 사용자 공간은 느슨하게 연결되어 있습니다. 부분적으로 이것은 디자인에 의한 것이고, 부분적으로는 필요에 의한 것입니다.

커널과 기본 사용자 공간을 함께 설계하고 유지 관리하는 BSD와 달리 Linux 커널과 사용자 공간은 다른 사람들이 개발하고 유지 관리합니다. 따라서 커뮤니티가 원한다고하더라도 서로 긴밀하게 연결하는 것은 어려울 것입니다.

또한 @sebasth는 Linux 커널 프로젝트의 주요 정책이 사용자 공간을 방해해서는 안된다는 훌륭한 지적을합니다. 느슨한 결합을 강제하는 또 다른 요소는 무엇입니까?

그러나 여전히 어느 정도의 결합이 있습니다. 충분히 오래된 리눅스 커널은 최신 배포판에서는 작동하지 않습니다.

제 이해는 리눅스 가 커널이고 다른 모든 것은 부수적이라는 것입니다. 일반적으로 커널 자체가 아닌 라이브러리에 묶여 있기 때문에 (많은) 설치된 패키지와 독립적으로 커널을 업그레이드 할 수 있습니다 . 일반적으로 커널 버전과 하드웨어 드라이버 (예 : GPU 드라이버) 간의 이러한 연결 만 볼 수 있습니다. 일부 소프트웨어는 특정 버전의 커널과 만 호환되지만 해당 프로그램의 개별 설명서에서 지정해야합니다.

시스템에 현재 사용되는 패키지와 이전에 설치된 패키지의 두 커널 패키지 제품군을 설치하는 것이 일반적입니다. 업그레이드 할 때 새 버전이 제대로 작동하는지 확인한 후 가장 오래된 버전을 제거해도 여전히 안전한 대체 방법이 있습니다. 예를 들어 Red Hat (및 사촌) package-cleanup --oldkernels --count 2은이를 자동적으로 수행해야합니다.

여기에있는 모든 좋은 주장 외에도 도움이 될 몇 가지 사항을 추가 할 수 있습니다.

우리는 이미 커널 팀 정책을 알고 있으며 Linux 배포판으로 커널 소스 코드를 가능한 한 순수하게 유지하려고 노력합니다. 즉, 취약점이 발생하거나 패치가 필요한 경우 커널 팀에 알리고 패치를 지원하려고하지만 최종 결정은 커널 팀의 결정입니다.

일부 배포판은 다른 배포판보다 추가 패치를 추가하지만 상위 개발자가 제공하는 패치를 유지하는 것이 좋습니다. 분명히 특별한 커널 구성, 특히 가상화 및 타사 드라이버가 필요한 일부 프로그램이 있으며 일반적으로 둘 다 특정 커널 버전 또는 적어도 오래된 버전에서 작동하는 데 사용됩니다 ... 그 이유는 그들이 시도하기 때문입니다 최신 커널 기능을 사용하려면 이전 커널로 실행하려고하면 제대로 작동하지 않을 수 있습니다.

명심해야 할 또 하나의 요소는 모든 Linux 배포판에 모든 소프트웨어가 시스템과 호환되는지 확인하는 관리자 팀이 있다는 것입니다. 그렇기 때문에 거의 모든 배포판에는 안정적이고 불안정한 버전이 있습니다. 개발자는 "불안정한"소프트웨어로 작업하고 모든 테스트를 마친 후에는 일반 사용자가 패키지를 업그레이드 할 수있는 후에 만 ​​안정적으로 표시합니다. 따라서 일반 사용자라고 요청한 사람이 90 % 안전하다면 소프트웨어가 잘 테스트되었습니다 .

따라서 사람, 공동체, 그리고 일반적인 접근 방식은 무엇입니까? 우리는 소프트웨어가 함께 작동하고 시스템을 손상시키지 않아야하므로 Filesystem Hierarchy Standard 와 같은 일부 표준을 따르려고합니다 .