Active Restore: С чего начать разработку в UEFI

[VioletGiraffe]

Подключение EDK я не осилил (хотя их руководства, наверняка, стоят внимания — я не видел этих материалов, когда изучал тему программирования под UEFI). Может быть, кому-то пригодится мой репозиторий с хедерами для работы UEFI и пример UEFI приложения c использованием этих хедеров (там есть и работающий проект для VS2019).

[DarkTiger]

Подключение EDK я не осилил

edk2 для VS2019 проблемно идет. В репозитории для этого отдельный файлик \Conf\tools_def_2019.txt лежит, но он все равно нерабочий, не доделанный до конца. Хотя тамошние тесты показывают, что все хорошо для VS2019.
Лучше использовать VS2015, дефолтный для edk2, и будет edk2 собираться автоматом, без ручного редактирования \Conf\targets.txt, с которым проблемы у начинающих

[JerleShannara]

Отличная статья, идеально подходит для начинающих разработчиков. Про будущие статьи — полностью поддерживаю.
П.С. После написания OpRom-ов для Legacy BIOS писать под UEFI одно удовольствие, хотябы исчезает ад с «а как мне себя в загрузку внести»(куча разных способов, которые по разному работают на разном железе) и ещё огромной кучи проблем, решаемых в UEFI вызовом одной функции.

[CodeRush]

Спасибо за статью, ждем следующих.

Сделаю несколько замечаний по коду, если позволите:
1. Есть такой TianoCore C style guide, и если писать что-то с расчетом на дальнейшее включение в EDK2, то лучше следовать ему, иначе есть неслабый шанс, что PR не примут. Более того, работать с кодом, который похож на «обычный» — приятнее.
2. Если используете goto FINALIZE;, лучше завернуть его в макрос вроде require(condition, label) или require_noerr(status_variable, label), это снизит нагрузку при чтении кода.
3. Не используйте ASSERT_EFI_ERROR() для проверки ошибок, особенно если у вас следующая операция — разыменование указателя, полученного от предыдущей. Из релизных конфигураций такие ассерты удаляются препроцессором, и потому вот эта операция — потенциальный источник бесконечного числа багов и потенциальная же дыра в безопасности.

[VioletGiraffe]

Хочу отметить, что №3 — постоянная проблема при программировании чего бы то ни было на С/С++, и я имею в виду любые проверки, а не только проверки на nullptr. Ещё лет 5 назад придумал такое решение, и мне оно до сих пор кажется удобным и изящным: особый вид assert макроса — assert_and_return, который проверяет условие и возращает указанный объект (или ничего). В релизе уходит сам assert/abort(), но остаётся проверка и выход. Вот пример:

#include "assert/advanced_assert.h"

bool doWork()
{
    assert_and_return_r(f1(), false);
    assert_and_return_r(f2(), false);
    assert_and_return_r(f3(), false);
    
    return true;
}

Без моего макроса была бы такая колбаса:

Скрытый текст

bool doWork()
{
    if (!f1())
    {
        std::cout << "Error calling f1()";
        return false;
    }

    if (!f2())
    {
        std::cout << "Error calling f2()";
        return false;
    }

    if (!f3())
    {
        std::cout << "Error calling f3()";
        return false;
    }
    
    return true;
}

А вот, собственно, моя реализация: github.com/VioletGiraffe/cpputils/tree/628ddff8b37bb11d8af336501f3dcb22f560cd7f/assert

[DarkTiger]

Статьи на хабре раз, два и три. Автору низкий поклон

Спасибо! Надо будет все же посмотреть по Ионеску, так руки у меня и не дошли тогда серьезно покопаться.
Еще стоит указать в статье, что Python надо поставить, без него edk2 не соберется. Неочевидная вещь для новичка, по выхлопу отлавливается, конечно, но не быстро — начнут чинить с явной ругани про переменную CYGWIN_HOME, а лучше внимание новичка на этом не фокусировать, он начнет, в попытках убрать ругань, cygwin ставить, а он там ни к чему при наличии VS.