미래는 이미 여기에 있거나 브라우저에서 직접 코딩할 수 있습니다.

나에게 일어났던 재미있는 상황과 유명한 프로젝트에 기여자가 되는 방법을 알려드리겠습니다.

얼마 전 나는 UEFI에서 직접 Linux를 부팅하는 아이디어를 생각해 보았습니다.
아이디어는 새로운 것이 아니며 이 주제에 대한 많은 매뉴얼이 있습니다. 그 중 하나를 볼 수 있습니다. 여기에

실제로 이 문제를 해결하기 위한 나의 오랜 노력은 완전히 공식화된 결과를 낳았습니다. 결정. 이 솔루션은 매우 효과적이며 일부 가정용 컴퓨터에서 사용하고 있습니다. 이 솔루션은 좀 더 자세히 설명되어 있습니다. 여기에.

UEFI-Boot의 핵심은 ESP(EFI 시스템 파티션) 파티션이 /boot 디렉터리와 결합된다는 것입니다. 저것들. 모든 커널과 부트스트랩 이미지(initrd)는 UEFI가 실행 파일, 특히 시스템 부트 로더를 시작할 수 있는 동일한 파티션에 있습니다. 그러나 많은 배포판의 Linux 커널 자체는 이미 UEFI에서 커널 자체를 시작할 수 있는 UEFISTUB 옵션으로 구성되어 있습니다.

이 솔루션에는 한 가지 불쾌한 순간이 있습니다. ESP 파티션은 FAT32로 포맷되어 하드 링크(initrd를 업데이트할 때 시스템이 정기적으로 생성함)를 생성하는 것이 불가능합니다. 그리고 이것에 대해 특별히 범죄적인 것은 없지만 커널 구성 요소를 업데이트할 때 시스템 경고를 보는 것은 그다지 즐겁지 않습니다...

또 다른 방법이 있습니다.

UEFI 부팅 관리자(OS 부트로더를 등록해야 하는 것과 동일)는 부트로더/Linux 커널 외에도 드라이버를 로드할 수 있습니다. 따라서 /boot가 있는 파일 시스템용 드라이버를 로드하고 UEFI를 사용하여 거기에서 직접 커널을 로드할 수 있습니다. 물론 드라이버는 ESP 파티션에 배치되어야 합니다. 이는 대략 GRUB와 같은 부트로더가 수행하는 작업입니다. 그러나 가장 중요한 점은 자주 사용되는 모든 GRUB 기능이 이미 UEFI에 있다는 것입니다. 더 정확하게는 다운로드 관리자에 있습니다. 더욱 지루하게도 UEFI 부팅 관리자는 일부 문제에 대해 훨씬 더 많은 기능을 가지고 있습니다.

그것은 아름다운 해결책인 것처럼 보이지만 "그러나"가 하나 있습니다(또는 오히려 그랬지만 이에 대해서는 나중에 더 자세히 설명합니다). 사실 UEFI 드라이버 시스템은 매우 간단합니다. 파일 시스템을 마운트하거나 드라이버를 특정 장치에 연결하는 것과 같은 것은 없습니다. 각 드라이버를 차례로 가져와 적어도 적합한 모든 장치와 연결하려고 시도하는 일반적인 이름 Map을 사용하는 시스템 호출이 있습니다. 그리고 운전자가 장치를 집어들 수 있으면 연결 기록인 매핑이 생성됩니다. 이것이 바로 새로 로드된 드라이버가 다른 모든 드라이버와 함께 공통 힙에서 초기화되어야 하는 방법입니다. 그리고 필요한 것은 드라이버 부팅 레코드에서 1비트(LOAD_OPTION_FORCE_RECONNECT)를 XNUMX로 설정하는 것뿐입니다. 그러면 UEFI는 이를 로드한 후 이 전역 재매핑을 수행합니다.

그러나 이것은 그렇게 쉬운 일이 아닙니다. UEFI 오프로드 관리자를 구성하는 데 사용되는 표준 efibootmgr 유틸리티는 이 비트를 설정하는 방법을 모릅니다(또는 방법을 몰랐습니다). 다소 복잡하고 위험한 과정을 거쳐 수동으로 설치해야 했습니다.

그리고 또 한 번 손으로 하려고 하다가 참지 못하고 형식화했어요. GitHub에서 문제 개발자에게 이 기능을 추가해달라고 요청합니다.

며칠이 지났지만 아무도 내 요청에 관심을 기울이지 않았습니다. 그리고 궁금해서 소스코드를 봤는데.. 포크해서 이 기능 추가하는 방법을 무릎 꿇고 생각해봤는데... 그런 건 설치한 적도 없고 소스 편집도 했기 때문에 “무릎 꿇고” 브라우저에서 직접 코드를 작성하세요.

나는 C(프로그래밍 언어)를 매우 피상적으로 알고 있지만 대략적인 해결책(주로 복사-붙여넣기)을 그렸습니다... 그런 다음 생각했습니다. 적어도 거기에는 많은 오류가 있을 것입니다(내 과거에 다른 사람의 언어를 편집하려고 시도했습니다). C 코드가 10번째쯤 완성되었습니다.) Pull Request를 발행하겠습니다. 잘 설계된.

그리고 거기에 Pull Request를 확인하기 위한 Travis CI가 첨부된 것으로 밝혀졌습니다. 그리고 그는 내 모든 실수를 부지런히 말했습니다. 글쎄요, 알려진 오류가 있으면 수정할 필요가 없습니다. 다시 한 번 브라우저에서 바로, 네 번째 시도에서 코드가 작동했습니다(나에게는 성취였습니다).

그런 식으로 브라우저를 떠나지 않고 거의 모든 최신 Linux 배포판에서 사용되는 유틸리티로 매우 실제적인 Pull Request를 포맷했습니다.

나는 언어를 실제로 알지 못한 채, 아무 것도 설정하지 않고(종속성 때문에 어셈블리에 꽤 많은 라이브러리가 필요함) 컴파일러를 실행하지도 않은 채 완전히 작동하고 유용한 기능을 단순히 "코딩"했다는 사실에 놀랐습니다. 브라우저.

그러나 내 요청은 19년 2019월 XNUMX일 이후 계속 응답이 없었고 나는 이미 그것을 잊어버리기 시작했습니다.

그런데 어제 이 요청이 마스터에 추가되었습니다.

그렇다면 내 이야기는 무엇입니까? 그리고 그는 현대 기술의 프레임워크 내에서 개발 도구나 종속성을 로컬에 배포하지 않고도 브라우저에서 실제 코드를 이미 작성할 수 있다는 사실에 대해 이야기하고 있습니다.

게다가, 이것은 이미 잘 알려진(적어도 좁은 범위에서) 유틸리티에 대한 나의 두 번째 풀 요청이라는 점을 인정해야 합니다. 지난번에는 SyncThing 웹 인터페이스의 일부 필드 표시를 수정해 달라는 요청으로 인해 전혀 모르는 환경에서 말 그대로 한 줄 편집이 이루어졌습니다.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

더 써야 하나 말아야 하나?

• 예

• 그만한 가치가 없다.

294명의 사용자가 투표했습니다. 138명의 사용자가 기권했습니다.

출처 : habr.com