Ще разкажа за куриозна ситуация, която ми се случи, и за това как да станеш контрибутор в известен проект.
Неотдавна се заех с една идея: зареждане на 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) не може (точно казано, не можеше) да задава този бит. Приходеше се да го задавам ръчно чрез доста сложна и опасна процедура.
И така, отново опитвайки се да направя това ръчно, не издържах и поисках с молба до разработчиците да добавят тази възможност.
Изминаха няколко дни, но никой не обърна внимание на молбата ми. И от любопитство погледнах изходния код… форкнах и обмислих "на коленете" как да добавя тази функция… "На коленете", защото не установих нищо на компютъра си и редактирах изходния код направо в браузъра.
C (език за програмиране) знам много повърхностно, но грубо накидах решение (предимно чрез копиране и поставяне)… а после си помислих — дори да имам там сигурно куп грешки (прошлите ми опити да коригирам чужд C код бяха успешни от десетия опит), ще подготвя Pull Request. И така .
А там се оказа, че е включен Travis CI за проверка на пулл реквестите. И той ми издаде всичките ми грешки. Е, ако грешките са известни — защо да не ги поправя: пак направо в браузъра, и от четвъртия опит кодът беше събран (постижение за мен).
И така, без да излизам от браузъра, подготвих напълно реален Pull Request за утилита, която се използва практически във всички съвременни дистрибутиви на Linux.
Самият факт, че аз, почти не знаейки езика и без да настроя нищо (там е необходима доста библиотека за зависимостите), и без да пускам компилатор, просто в браузъра написах напълно работеща и полезна функция, изненада и мен.
Но моята заявка нямаше реакция от 19 март 2019, и вече започнах да я забравям.
Но ето, вчера тази заявка беше добавена в master.
А с какво да ви запозная? Оказа се, че в рамките на съвременните технологии реалният код вече може да се пише в браузър, без да се разгръщат локално никакви разработвачески инструменти и зависимости.
Трябва да призная, че това е вторият ми pull request в известни (по всяка вероятност в тесни среди) утилити. Предишния път, когато поисках да поправят визуализацията на някои полета в уеб интерфейса на SyncThing, получих буквално едно-редова поправка в среда, която изобщо не познавам.
Само регистрирани потребители могат да участват в анкетата. , моля.
Дали да пиша още или не?
да
ако вашите низове са достатъчно дълги (от 100-200 символа). В такъв случай си струва да обмислите използването на алгоритми за компресия, като deflate.
294 потребителя гласуваха. 138 потребителя се въздържаха.
Източник: habr.com
