А зачем вообще нужен UEFI?

Не-не-не, Девид Блейн. Где я в исходных данных указывал умение кодить? А то так можно сказать «возьми и напиши свой биос без недостатков, делов-то».

Ах да, еще добавлю к 1 пункту: UEFI заранее знает где находится загрузчик, а не ищет его в MBR.

возьми и напиши свой биос без недостатков, делов-то

без спеков на чипсет и процессор? Которые успешно зажимаются из-за наличия биоса, кстати

Это всё детали, правда же? Главное - принципиальная возможность, правильно?

Где я в исходных данных указывал умение кодить?

ты про тех, кто не умеет сказать своей эвм, что ей делать?

Без спеков - невозможно

С UEFI можно и вообще без загрузчика, CONFIG_EFI_STUB.

ты про тех, кто не умеет сказать своей эвм, что ей делать?

Ололо. Так вы ответите на мой изначальный вопрос, или будете сливать?

UEFI заранее знает где находится загрузчик, а не ищет его в MBR

Нечего там искасть. У стандартного MBR bootstrap code находится по фиксированным смещениям.

Ответ таков: или ты что-то неправильно спрашиваешь, или же создатели grub как-то очень странно написали, или же у тебя был особенно кривой биос. Потому что int 13h обращается к каждому hdd по-отдельности

Это не отменяет того что UEFI будет заранее знать где находится ядро.efi, а не искать в MBR загрузчик как BIOS, но да, это еще ускоряет загрузку, по сравнению с использованием загрузчика для UEFI.

Ну хз, я прочитал где-то что BIOS ищет загрузчик, в то время как UEFI заранее знает где он находится.

может у тебя рейд?

Ну хз, я прочитал где-то что BIOS ищет загрузчик, в то время как UEFI заранее знает где он находится

GRUB ищет stage2, а BIOS просто загружает stage1. http://en.wikipedia.org/wiki/Master_boot_record — всё заранее известно за исключением случая для NEWLDR MBR.

Нет.

Тогда это какая-то кривость. Может быть grub не int 13h использует?

В доках ко второму грубу написано, что передача управления загрузчику при chain loading'е происходит в реальном режиме.

а ещё , если не ошибаюсь , обещали драйвера для устройств впихивать в уэфи, а ос будет взаимодействовать с ними через стандартные интерфейсы

что передача управления загрузчику при chain loading'е происходит в реальном режиме.

это еще не гарантирует int 13h

А вот плохо это. Ибо проприетарщина выйдет

Собрать ядро - дело 30 минут

Гораздо меньше. Но сколько времени ты потратишь на то, чтобы сконфигурировать его?

стандартные интерфейсы

Тебе-то какая разница, что там уровнем абстракции ниже, если все возможности доступны?

Да, кстати, у UEFI сорцы доступны, у BIOS - нет(Coreboot не в счёт, учитывая то, какими средствами он написан).

у UEFI сорцы доступны

особенно у гипотетических проприетарных драйверов, ага.

если все возможности доступны?

int 13h хватит всем.

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

Нет, сложнее. Внезапно, secure boot защищает от гипервизоров, в которые могут эволюционировать руткиты (под онтопиком руткитов уже более, чем достаточно). Параноики, не доверяющие производителям железа, идут лесом.

Параноики, не доверяющие производителям железа, идут лесом.

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

Да, кстати, у UEFI сорцы доступны

Как это? Разве UEFI это не всего лишь спецификация, реализации которых различны? Знаю только, что есть свободная реализация UEFI, являющаяся надстройкой над Coreboot. Но тут у BIOS дела ничуть не хуже.

Спецификация, да. И речь о том, что есть свободные реализации, можно хоть самому приложения писать. Для BIOS подобного нет.

являющаяся надстройкой над Coreboot

Coreboot просто использовал её в качестве payload.

Производители на это дружно все забили.

Свободных реализаций нет. На основе edk2/tianocore никогда не собрать работающий образ флешки для прошивки - потому как ве это лишняя обертка, не инициализирующая собственно оборудование. А у Phoenix, AMI, Insyde у каждого свои реализации, хотя и включающие в себя код tianocore. Вообще UEFI ненужная хрень (которую писали рукожопые люди - вы только посмотрите на код, абстракция над абстракцией), добавляющая излишней сложности там, где она не нужна. Можно сказать, вполне полноценная OC. Но и малварь на неё скоро появится :)

И правильно - http://www.securitylab.ru/contest/430512.php Вообще советую почитать также и другие статьи этого автора.

просто начального загрузчика, загружающего ОС или grub и не делающего более ничего

Да ничем, в принципе, но coreboot не очень-то распространён.

Я бы не сказал что прекрасно. Как там с поддержкой дисков больше 2TB?

Все хорошо там.
Поддерживается загрузка с HDD объемом более 3 Тб без создания дополнительных разделов.
Я не имею ввиду биосы на платах под первопни, конечно же.
На платах под 1155/FC2/... (с биосами) все ок.

Мышкой можно было тыкать в bios'ах.

Как там с поддержкой дисков больше 2TB?

А что с ней?

http://ru.wikipedia.org/wiki/Extensible_Firmware_Interface

вот почитай для начала, если не отпадут вопросы, задавай более конкретные вопросы.

Я так понимаю, что UEFI - это программная обертка вокруг железа, позволяющая абстрагировать доступ к нему. Фактически - это API, реализуемый железячным вендором.

В принципе, идея, если отбросить secure boot, очень хлебная, имхо.

В принципе, идея, если отбросить secure boot, очень хлебная, имхо.

плохая идея. Нечего еще один слой виртуализации ставить

Но когда говорят о устаревании биоса, зачем-то предлагают ввести куда больший uefi, вместо того, чтобы выкинуть из bios старый хлам, оставив и упорядочив только необходимое.

BIOS требует то, что кроме него уже никто не использует или без чего вполне мог бы обойтись. Я имею ввиду текстовый режим экрана и реальный 16-битный режим процессора. Фактически, BIOS единственное, почему это ещё держат.

Даже тупой DOS использовал свои драйвера, а не int 13h

Собственно вы не правы. Отдельные драйвера использовались для cdrom и некоторых отдельных контроллеров. Но с большинством DOS работал через int 13, как собственно, и freedos сейчас.

BIOS имеет процедуру, которая опрашивает контроллеры и позволяет устанавливать обработчики прерываний (это я упрощённо), т.е. драйвера прошиты в ROM контроллера и устанавливаются на int 13 при загрузке.

с большинством DOS работал через int 13

да ну? А я в какой-то книге по IBM AT видел драйвер работы с FDD без int 13h

Да, давайте в grub запихнём поддержку всех трёх тысяч армодевайсов. И в lilo заодно. И в extlinux, там им и место.

Алсо это не виртуализация, а интерфейс.

Алсо это не виртуализация, а интерфейс.

если быть точным, то да, но по факту вместо реального железа под ОС работает с проприетарными функциями из uefi.

Не ОС, загрузчик. ОС обычно забивает на всё это. Кроме специальных случаев (часто ли используется видеобиос?)

Что до grub, то на arm используется больше uboot, таки умеющий работать на различных девайсах.

А загрузчику на x86 только hdd и usb и нужны, а они стандартизированы.

А на arm там все равно платформозависимость есть и будет из-за большого зоопарка перефирии.

Потому, что для него дописали поддержку каждого устройства. И он работает далеко не везде.

Да, именно поэтому.

И это не говоря о том, а куда собственно ты собрался записывать это uefi на arm? Что, ставить еще одну флешку? А может у меня каждый квадратный миллиметр на счету?

Стоп, кто сказал, что оно претендует на embedded? UEFI будет только на десктопах, планшетниках и телефонах. Там оно вполне к месту.