Загрузочные настройки сохранять хорошо, но в kernel.mnt... а что, если в новой версии ядра установки будут храниться по другому адресу? Менять при каждом новом ядре загрузчик?
У Вилле в M64 настройки хранятся в config.mnt, который грузится там же, где и kernel.mnt - в bootloader'е. И мне кажется, что такой подход лучше.
Загрузка с HD.
diamond
1) У меня стоит 98SE на Fat32, а вопрос о Fat16 идет как резерв. Нежелательно заранее ограничивать возможности загрузчика. Лучше иметь все. Впрочем, решать тебе ты же автор.
2) А кто нам мешает впихнуть в загрузочный сектор микрокод, который запустит твой загрузчик?
Иван Поддубный
Такой подход лучше и мы, кажется, такие идеи уже обсуждали. Даже хотели сделать, чтобы был счетчик - если никакая кнопка не нажимается, то ядро грузиться с предустановленными параметрами, а если нажимается то предлагается ввести параметры.
1) У меня стоит 98SE на Fat32, а вопрос о Fat16 идет как резерв. Нежелательно заранее ограничивать возможности загрузчика. Лучше иметь все. Впрочем, решать тебе ты же автор.
2) А кто нам мешает впихнуть в загрузочный сектор микрокод, который запустит твой загрузчик?
Иван Поддубный
Такой подход лучше и мы, кажется, такие идеи уже обсуждали. Даже хотели сделать, чтобы был счетчик - если никакая кнопка не нажимается, то ядро грузиться с предустановленными параметрами, а если нажимается то предлагается ввести параметры.
1) Все preboot-параметры хранятся в первом секторе kernel.mnt. От версии ядра ничего не зависит - загрузчик просто записывает назад первый сектор.
2) Собственно говоря, загрузчик при желании может сохранять вышеупомянутый первый сектор или конкретные данные из этого сектора куда угодно - было бы свободное пространство для кода в загрузчике и желание автора. Подход как в пункте 1) сделан для простоты модификации существующего загрузчика.
3) Легко добавить (расширив интерфейс загрузчика) поддержку считывания/записи параметров с адреса, предоставляемого загрузчиком. Было бы желание и, опять же, свободное пространство для кода в загрузчике и желание автора.
2) Собственно говоря, загрузчик при желании может сохранять вышеупомянутый первый сектор или конкретные данные из этого сектора куда угодно - было бы свободное пространство для кода в загрузчике и желание автора. Подход как в пункте 1) сделан для простоты модификации существующего загрузчика.
3) Легко добавить (расширив интерфейс загрузчика) поддержку считывания/записи параметров с адреса, предоставляемого загрузчиком. Было бы желание и, опять же, свободное пространство для кода в загрузчике и желание автора.
При разработке загрузчика с какого бы то ни было устройства хранения данных возможны две задачи:
1) С этого устройства никакая операционная система не загружается. (Как вариант, нам не жалко операционной системы, загружающейся оттуда).
2) С этого устройства уже худо-бедно загружается какая-нибудь ОС и после наших вмешательств она должна по-прежнему худо-бедно загружаться.
mtldr работает в условиях задачи 2) при наличии Windows (кроме Me) и/или (возможно) DOS.
Нетрудно добавить к mtldr'у код, позволяющий загрузку напрямую из bootsector'а (mtldr'у главное - получить управление, никаких средств ОС он не требует). Вопрос в том, что если мы собрались решать задачу 1 и писать bootsector, мы уже знаем тип файловой системы, так что универсальность нам не нужна, а универсальность в данном случае оборачивается раздуванием кода (разбор FAT12 можно целиком запихнуть в bootsector, а mtldr формально занимает 10h секторов (это требование NT-загрузчика), хотя реально занято там меньше половины.)
1) С этого устройства никакая операционная система не загружается. (Как вариант, нам не жалко операционной системы, загружающейся оттуда).
2) С этого устройства уже худо-бедно загружается какая-нибудь ОС и после наших вмешательств она должна по-прежнему худо-бедно загружаться.
mtldr работает в условиях задачи 2) при наличии Windows (кроме Me) и/или (возможно) DOS.
Нетрудно добавить к mtldr'у код, позволяющий загрузку напрямую из bootsector'а (mtldr'у главное - получить управление, никаких средств ОС он не требует). Вопрос в том, что если мы собрались решать задачу 1 и писать bootsector, мы уже знаем тип файловой системы, так что универсальность нам не нужна, а универсальность в данном случае оборачивается раздуванием кода (разбор FAT12 можно целиком запихнуть в bootsector, а mtldr формально занимает 10h секторов (это требование NT-загрузчика), хотя реально занято там меньше половины.)
diamond
Еще как зависит от версии ядра расположение preboot-параметров. Возможно, оно не менялось уже несколько месяцев, но это не значит, что в следующем дистрибутиве смещение этих параметров в файле kernel.mnt не изменится.
Еще как зависит от версии ядра расположение preboot-параметров. Возможно, оно не менялось уже несколько месяцев, но это не значит, что в следующем дистрибутиве смещение этих параметров в файле kernel.mnt не изменится.
preboot.inc включается одним из первых (чуть ли не первым, в котором содержатся код/данные). Так что он в начале
(заметьте, я не утверждаю, что в самом начале и даже не утверждаю, что по фиксированному смещению). В первый сектор влезает.
В моем варианте ядра на всякий случай в конце preboot.inc добавлено
if $>10200h
ERROR: preboot parameters must fit in first sector
end if
Так что случайно выйти за пределы первого сектора не получится. А нарочно не стоит.
(заметьте, я не утверждаю, что в самом начале и даже не утверждаю, что по фиксированному смещению). В первый сектор влезает.
В моем варианте ядра на всякий случай в конце preboot.inc добавлено
if $>10200h
ERROR: preboot parameters must fit in first sector
end if
Так что случайно выйти за пределы первого сектора не получится. А нарочно не стоит.
Есть какие-нибудь пожелания по mtldr'у в связи с задачей 1? задачей 2?
diamond, c [abcd] все ок! Просто я уже успел привыкнуть к [1234], успею отвыкнуть.
Я немножко не понял, будет ли загрузчик некой надстройкой перед загрузчиками MicroSoft-систем и колибри которая позволит выбирать между ними?
Я немножко не понял, будет ли загрузчик некой надстройкой перед загрузчиками MicroSoft-систем и колибри которая позволит выбирать между ними?
В том то и дело, что загрузчик mtldr грузится после загрузчика Microsoft. Но есть более опасные варианты, когда загрузчик грузится перед загрузчиком windows или другой ОС, которые можно реализовать.
Так чего мы решим с
а) улучшенным синим экраном загрузки?
б) загрузчиком с дискеты, сохраняющим параметры?
Внедряем в ядро или нет?
а) улучшенным синим экраном загрузки?
б) загрузчиком с дискеты, сохраняющим параметры?
Внедряем в ядро или нет?
diamond
С внедрением в ядро надо аккуратней, чтобы оно не мешало тем, у кого нету мелкософтовских систем.
А так оба варианта интересны.
С внедрением в ядро надо аккуратней, чтобы оно не мешало тем, у кого нету мелкософтовских систем.
А так оба варианта интересны.
Причем тут мелкософтовские системы? mtldr абсолютно никак не связан с загрузчиком с дискеты и синим экраном загрузки ядра, о которых как раз и идёт речь. А загрузчик с дискеты и улучшение экрана загрузки никак не используют наличие/отсутствие каких бы то ни было других операционных систем (включая другие экземпляры Kolibri )
А если винт был отформатированный и без системы, то можно mtldrом колибри с него грузить а не с дискеты? И вообще существовал ли такой загрузчик ранее?
Нужны загрузочные части DOS или Windows. Для чистых разделов придется либо модифицировать текущий загрузчик (если в начале диска имеется по крайней мере 8Kb свободного пространства до таблицы FAT/MFT) либо написать новый.
Если не будет существенных возражений, то дня через 2-3 залью изменения на svn.
Если не будет существенных возражений, то дня через 2-3 залью изменения на svn.
"Отформатированный и без системы" винт - это (в моей вышеупомянутой терминологии) задача 1, mtldr (в существующем варианте) в этом случае практически бесполезен. Проще и экономичнее написать новый загрузчик для этой задачи. Есть необходимость? Если есть, то для какой файловой системы?
Who is online
Users browsing this forum: No registered users and 3 guests