Майбутнє вже тут або кодуємо прямо у браузері

Розповім про курйозну ситуацію, що трапилася зі мною, і про те, як стати конриб'ютором у відомий проект.

Нещодавно порався я з однією ідеєю: завантаження Linux безпосередньо з UEFI…
Ідея не нова і є кілька мануалів на цю тему. Один із них можна подивитися тут

Власне, мої давні спроби вирішити це питання вилилися в цілком оформлене. рішення. Рішення цілком робоче, і я його використовую на частині своїх домашніх машин. Трохи докладніше це рішення описано тут.

Суть UEFI-Boot у цьому, що ESP (EFI System Partition) розділ поєднується з каталогом /boot. Тобто. всі ядра, і образи початкового завантаження (initrd) розміщуються тому самому розділі з якого UEFI може запускати виконувані файли і зокрема запускати завантажувачі системи. Але саме ядро ​​Linux вже у багатьох дистрибутивах збирається з опцією UEFISTUB, яка дозволяє саме ядро ​​запустити з UEFI.

Є у цього рішення один неприємний момент — розділ ESP відформатований у FAT32, на якій неможливо створити жорсткі посилання (які система створює регулярно при оновленні initrd). І нічого особливо кримінального в цьому немає, але бачити попередження системи при оновленні компонентів ядра — не дуже приємно.

Є й інший шлях.

Менеджер завантаження UEFI (той куди потрібно прописати завантажувач ОС) вміє крім завантажувачів/ядер Linux завантажувати ще й драйвери. Отже, можна завантажити драйвер тієї файлової системи, де у вас лежить /boot і прямо звідти завантажувати ядро ​​засобами UEFI. Драйвер, само собою, потрібно покласти до розділу ESP. Приблизно цим займаються завантажувачі типу GRUB. Але особливість саме в тому, що всі часто використовуються функції GRUB вже є в UEFI. Точніше у його менеджері завантаження. А якщо бути ще зануднішим, то у менеджера завантаження UEFI є навіть більше можливостей у деяких питаннях.

Начебто гарне рішення, але є одне «АЛЕ» (вірніше було, але про це пізніше). Справа в тому, що система драйверів UEFI влаштована досить простенько. Там немає такого поняття як монтаж файлової системи або зв'язування драйвера з конкретним пристроєм. Там є системний виклик з умовним ім'ям Map (англ.), який бере по черзі кожен драйвер і намагається зв'язати його з усіма, хоч якось придатними пристроями. І якщо драйвер пристрій зміг підчепити, то створюється мапінг - сполучний запис. Саме так у спільній купі з усіма іншими і повинен ініціалізуватися знову завантажений драйвер. І ось всього-то і потрібно - в завантажувальному записі драйвера поставити один біт (LOAD_OPTION_FORCE_RECONNECT) в 1 і UEFI після його завантаження зробить цей глобальний ремап.

Тільки ось зробити це не так просто. Стандартна утиліта efibootmgr (засобами якої і здійснюється налаштування менеджера розвантаження UEFI) не вміє (точніше не вміла) ставити цей біт. Доводилося руками його ставити через досить складну та небезпечну процедуру.

І ось вкотре спробувавши зробити це руками я не витримав і оформив issue на GitHub з проханням до розробників додати цю можливість.

Минуло кілька днів, але на моє прохання ніхто не звернув уваги. І я з цікавості глянув на вихідники… форкнув, та й прикинув «на колінах» як цю фічу додати… «На колінах» бо нічого такого собі не ставив і просто в браузері вихідники редагував.

C (мова програмування) я знаю дуже поверхово, але приблизно рішення накидав (переважно копі-пастом)… ну а потім подумалося — а хоч у мене там напевно купа помилок (минулі мої спроби правити чужий C-код збиралися з 10-го) оформлю я Pull Request. Ну і уклав.

А там виявився прикручений Travis CI на перевірку пулл реквестів. І він мені старанно усі мої помилки видав. Ну якщо відомі помилки - що б і не виправити: знову прямо в браузері, і з четвертої спроби код зібрався (досягнення для мене).

І ось так, не вилазячи з браузера, я оформив цілком реальний Pull Request в утиліту, яку користуються практично у всіх сучасних дистрибутивах Linux.

Мене самого здивував той факт, що я, толком не знаючи мови, і нічого в себе не налаштовуючи (там по залежностях не мала пачка бібліотек для складання потрібна) і не разу навіть компілятор не запускаючи, просто в браузері «накодив» цілком робочу і корисну фічу .

Однак реквест мій висів без реакції з 19 березня 2019 року, і я вже почав про нього забувати.

Але вчора цей реквест додали в master.

Так про що ж моя розповідь. А він про те, що в рамках сучасних технологій виявилося, що справжній код вже можна писати в браузері, не розгортаючи локально ніяких девелоперських інструментів і залежностей.

Причому, треба сказати, це вже другий мій пулл реквест у відомі (принаймні у вузьких колах) утиліти. Минулого разу моє прохання поправити відображення деяких полів у web-інтерфейсі SyncThing вилилося в моє буквально однорядкове виправлення в середовищі, яке я взагалі не знаю.

Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.

Писати ще чи не варто

• да

• не варто

Проголосували 294 користувачів. Утрималися 138 користувачів.

Джерело: habr.com