OSDev

16 КБ стандартное значение стека начиная с DOS и далее перекочевало в виндоус.
8 КБ очень мало, так как у меня в стеке к примеру лежат строки(256 Б каждая) и буфер для чтения из файла (512 Б ). И функции одна вызывает другую и их очень много. Более 4 КБ


У MZ-EXE так с начало идет код, потом стек, потом куча.
А вот у PE наоборот сначала стек, затем код, потом куча.
Расположение стека не принципиально главное что-бы при его переполнение(в обе стороны) не повредил код или данные. Да и вообще размер стека определяет разработчик программы, а не система.


Я уже давно решил что вначале мне нужен вторичный загрузчик, который проведет настройку системы в реальном режиме. На данный момент я неготов от него отказаться. Вернее не вижу как.

Дубль два: "Размер файла сокращать не пришлось бы". Минимальной реорганизации загрузчиков, думаю, хватило бы. А кратность базы стала бы еще лучше. То что размер образа должен быть кратен размеру сектора, я вообще первый раз от тебя слышу. Может, ты неправильно выразился?

При наличии спек я в демо-исходники редко заглядываю. А если и заглядываю, то только чтобы убедиться по-быстрому, что в них присутствует именно, что я ожидаю там увидеть.

Для тебя может и нереально. Но попытаемся представить, что я (опять гипотетически) захотел бы поддержать твой формат ядра в своих вторичных загрузчиках. Конечно я подобробно бы изучил твои спеки, все реализовал в точном соответствии с их содержимым. И тут пользователь твоих загрузчиков вдруг видит, что мой вторичный загрузчик стал поддерживать твой формат ядра. Конечно он попытает проверить, как это работает, и загрузить свое самопальное ядро при помощи моего вторичного загрузчика, но мой вторичный загрузчик, будучи расположенным во втором меге (ядро загрузчика реально может располаться во втором меге, когда грузит что-то в первый), просто проверит, достаточно ли базовой памяти для загрузки образа, и успешно его загрузит. Тут начнет выполняться код пользователя, который конечно же писал его по представленному тобой образцу и в соответствии с твоими устными рекомендациями. А свободной памяти после образа нет (например, пользователь для этих экспериментов выбрал комп, для которого BIOS писали какие-то идиоты, или просто на этом компе хакинтошка завелся). Зато есть проблемы. Кто в этом будет виноват?

Не знаю. GRUB, SYSLINUX, мои вторичные загрузчики - везде стек в начале памяти. У меня в ядре такая же ситуация с начальным стеком, причем он весьма интенсивно используется, как с вершины, так и со дна:Кстати можешь глянуть на картинку в этой теме с распределением базовой памяти для вторичного загрузчика/ядра. По-моему все достаточно аккуратно. Я как раз не использую на начальном этапе свободный участок, находящийся в конце, тем более что его может и не быть. А участок, находящийся в начале, использовать очень удобно.

Прижмет, напишешь. Или будешь тянуть в свой дистр сторонний софт со всеми вытекающими.

Я тоже пока не готов отказаться от инициализации в реальном режиме, но это мне не мешает использовать "Multiboot entry point". А линух обычно стартует в RM

Никто не говорит, что 8 кБ это достаточно для задачи. Однако, для начальной инициализации системы этого вполне хватает. А иногда и не только для инициализации. В Линуксе, например, стек ядра составляет 4к. Это раз.
Если вдруг стека 8к действительно мало, - ну так никто не заставляет грузить все 620к образа! Грузи меньше, под стек останется больше. Это два.


Слуште, я не понимаю, у всех тут так всё очевидно получается, один я тупой. У нас ОЧЕНЬ МАЛО базовой памяти, всего 640 к и даже того меньше, а все хотят сразу и базу поднять и под стек выделить 32к и при этом чтобы 620к образа по-прежнему грузились. Пойми - поднимаешь базу ради (весьма куцего) стека под ней, - автоматически нарываешься на потенциальные проблемы с EBDA. Либо сокращаешь доступное загрузчику пространство, которого и так впритык. Я не могу просто взять и выделить внизу 4к под какой-то буфер потому что 1) выделенного буфера, как такового, нет, все области по максимуму шарятся; 2) потребуются релокации, а это дополнительный код, немаленький, под который нет места в загрузчиках, по крайней мере в FAT12/16 и Ext2/3.


Кратность требуется только для флопа. Современные устройства с большими секторами будут работать и так.


Размер не должен быть кратен вообще, он должен быть кратен в моём случае.
1. Мне намного проще проверять, исчерпался ли лимит загрузки (если файл >620к).
2. Если я заложу размер, не кратный сектору, при чтении последнего (большого) сектора произойдёт overrun и будет затёрта часть данных загрузчика, т.к. BIOS не может считать только кусок сектора.


Организация стека никак не относится к спецификациям загрузки. Всё, что происходит после передачи управления - на совести разработчика ядра. Но я понял, я напишу в документации, что именно гарантируется и как этим лучше воспользоваться.


GRUB, SYSLINUX и твои загрузчики умеют грузить 620к? Ну так и что тогда ломать копья?
Я вообще не понимаю, в чём проблема-то? Либо пишешь маленький стаб-релокатор, как в твоём втором образе ГРУБа, и переносишь ядро вверх (только тогда забудь про 620к), либо дополняешь нулями, как в первом образе. Пойми, ВВЕРХ что-то перенести - не проблема. А вот ВНИЗ гораздо проблематичней.


Участок в начале - это частное решение твоего ядра. У меня, например, нет такого участка и нет необходимости в нём. Участки нужного размера резервируются и чистятся (BSS) сразу после образа. Что мешает тебе зарезервировать те же самые 32к под стек после образа и сделать в ядре ORG 600h? Это же просто поменять местами два куска, как два пальца об асфальт. Я пытаюсь сделать начальную загрузку такой, чтобы она годилась для всех, по крайней мере с заглушками, и пока что имеющийся вариант это допускает. Если подниму базу - загрузка перестанет быть универсальной.


Пока не вижу причин, почему меня должно прижать. И потом, вторичная загрузка - это уже совсем другая тема. Здесь мы обсуждаем первичную.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Не надо сваливать все в одну кучу. Про базу в 32 Кб я сейчас говорил только в качестве примера. Во вторичном загрузчике я под этой базой помимо стека еще 24-килобайтный драйвер размещаю (правда после инициализации 1 Кб в конце доступного ему пространства отбирается, но это уже мелочи). Под стек остается 6,75 Кб (за вычетом IVT+BDA). Последний раз я предлагал тебе сделать базу 2 Кб, а не 32. Такой низкой базы тоже практически ни у кого нет.

Я не могу понять, почему ты эти 768 байт не можешь задействовать под нужды первичного загрузчика и за счет этого высвободить в конце 512 байт, чтобы размер загружаемого файла не пострадал. Тебе что архитектурно трудно разнести работу по разным участкам? "Куцый стек" размером 768 байт (это уже близко к обычно устанавливаемому мной 1 Кб в исходниках mksys) мне внушает значительно больше доверия, чем "сиротские" 256 байт (хотя их конечно можно задействовать под переменные), а кроме того за счет этого мне можно уменьшить размер файла на размер стекового дампа в нем и не пытаться распределять стек после образа, что, как ты понимаешь, уменьшает вероятность "нарваться на потенциальные проблемы с EBDA". Но в принципе если ты "дашь народу" свободный участок определенного размера после образа, этого будет достаточно.

Я последний раз говорил про лучшую кратность базы 800h по сравнению с 600h. Да, возможно, практического смысла в этом не много, но ведь это красиво, особенно при чтении CD/DVD

Как уже сказал, я не предлагаю тебе уменьшать размер файла.

Если ты читал, что у меня написано, то видел, что там нет указаний на то, где нужно размещать стек. Там лишь присутствует описание различных участков памяти и даются указания, направленные на предотвращение разрушения данных текущим стеком (или просто другими данными - это есть в описание первого интерфейса, чтобы не были случайно уничтожены данные в дескрипторе загрузочного раздела). Как уже сказал выше, если напишешь, этого в принципе будет достаточно.

Про GRUB я тебе уже рассказывал. mboot, может, и сможет, т.к. в сервисе syslinux'а есть функции зачистки и переноса финальной стадии в нужный участок памяти. У меня пока драйвер и стек не могут быть перемещены штатными средствами (т.е. первый 31 Кб памяти трогать нельзя), апплеты могут быть перемещены только в пределах доступной для них базовой памяти. В дальнейшем при необходимости все эти ограничения можно снять. ВНИЗ можно перенести точно также, как и ВВЕРХ.

Кстати (только не ругайся ) базу можно сделать вообще равной 2000h. Тогда получится красивая картинка:

• 8 Кб - IVT, BDA и все твое добро;
• 620 Кб - образ;
• 12 Кб - твой резерв для EBDA.

Если вдруг в будущем EBDA будет уличена в наползании на буфер, который ты зарезервировал для образа, будешь его по мере надобности уменьшать. А чтобы пользователь твоих загрузчиков, рассчитывающий на все 620 Кб, не пострадал, при наличии буфера меньшего размера будешь выдавать сообщение об ошибке вместо передачи управления ядру, ну или перестанешь гарантировать загрузку 620 Кб (можно к примеру реальный объем загруженного передавать ядру в качестве параметра, а гарантировать вообще "пару килобайт", чтобы код ядра смог сам разобраться в том, что образ загружен не полностью, и сообщить об этом; если ты будешь еще и требовать наличия в образе этой "пары килобайт", то избавишь пользователя от ошибки случайного обрезания образа - у меня к примеру образ ядра никак не может быть меньше 1 Кб и как раз в первом килобайте находится код валидации ядра).

Память перед образом "статична" и всегда доступна для работы. Доступность памяти после образа нужно проверять в ядре, используя текущий стек, или предоставлять определенный участок загрузчиком (причем если он подвижен, то могут возникнуть проблемы с обрезанным образом, а если статичен, то могут возникнуть проблемы с EBDA).

OK, я просто предложил альтернативу "заглушкам на все случаи жизни". У таких заглушек есть один недостаток: они требуют дополнительной обработки. Т.е. чтобы мне к примеру получить sys-образ, я должен прогнать оригинальный файл(ы) через mksys или по крайней мере сделать что-то типа "copy /b /y ... kernel.sys" (последнее возможно не для всех форматов, если это не какой-то специализированный конвертер).

P.S. Уже несколько постов подряд забываю тебя попросить прибавить к текущей версии хотя бы сотку.

Потому что этот рваный кусок никуда толком не пристроить.
Я не могу понять, почему ты так любишь фрагментацию памяти.
У нас на работе есть один сотрутник, аникейщик. Вот он категорически любит разбивать винчестер на разделы. Если ему императивно скажешь: "Не разбивай винт, зараза!", - то он разобъёт его всего на два раздела, один системный (туда поставит ОСь), один пользовательский (туда ставит приложения). В противном случае сделает минимум три раздела - ещё один под инсталляшки. Я бессилен с ним воевать, не помогает даже то обстоятельство, что при установке новой ОС на старый комп места на системном разделе не хватает (а то даже и в процессе эксплуатации после обновлений), либо же (если сделает "с запасом") приходится в системный раздел допихивать разросшуюся пользовательскую ботву. Войны приводят к тому, что он начинает колдовать Партишен-Мэджиком, менять размеры разделов, затем дефрагментировать, переносить данные, затем перенастраивать в ПО ссылки на сменившиеся буквы дисков и всё это затягивается на неделю-две. Вот до него не доходит, что достаточно не разбивать диск на разделы, тогда не возникнет свистоплясок. Он считает, что должна быть структура в ущерб гибкости.
Здесь весьма похожая ситуация.
Ты предлагаешь фрагментировать память. Вот этот кусок для этих целей, другой для тех, а сюда в разрыв положим образ. В жизни так не бывает. Предположим даже, сейчас я напрягусь, распихну. А для другой ФС я раскидать данные не смогу. И что делать?
Наиболее адекватный подход - минимальная фрагментация памяти, причём загрузка в наименьшую возможную базу. Только тогда я могу нормально распределить память для загрузчика. Единственно, что может пострадать в дальнейшем - размер образа, если вдруг выяснится, что места не хватает. Но это будет относительно малая кровь. А вот если плюс к этому начнутся пертурбации с базой, это будет уже неприятно.


Загрузка с CD/DVD работает. Про базу 600h - см постулат выше: должна быть минимальная возможная база.


Можно. Но (1) сложней и (2) в ущерб размеру образа. Если база повышается сильно, то размер определённо пострадает. Если база повышается не сильно, то дополнительные 256 байт тебя не спасут, а в большинстве случаев (другие ОСи) просто пропадут даром.


Не, некрасивая. Сейчас мне удаётся вписаться в 8к. Но нет никакой гарантии, что удастся вписаться с другими нетривиальными ФС. Начнётся разбор какой-нибудь BTRFS и там выяснится, что нужно 9к, причём кусок размером 1к я выделить вверх не могу. И что делать? В рамках постулата "минимальная возможная база" пострадает только размер образа. В других случаях ещё и база.
Кроме всего этого, мне в принципе не нравится идея "завести пустой кусок снизу впритык к таблице векторов". Для моего ядра, например, это просто потеря этого куска. Если бы это была целая страница, я ещё мог бы кинуть её в пул свободных страниц, но там ведь вектора прерываний. Значит я должен старательно добивать её какими-то данными. Под любые стеки я всегда отвожу только целые страницы, - так можно контролировать переполнение. А если стек налезет на вектора прерываний - это будет неконтролируемый achtung.


Это проверяется очень просто. Несколько ассемблерных инструкций.


Можно использовать один из имеющихся вторичных загрузчиков. Хотя бы тот же ГРУБ.


В смысле? Сотку чего?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Кто сказал? Лучше оставлять незадействованную память в конце, чем в начале.

Если в компе один винт, то его лучше разбить на два раздела (это минимум, т.е. без учета наличия нескольких ОС, раздела подкачки и т.п.). Второй раздел как раз и нужен для "пользовательской ботвы". Естественно, я говорю о современных винтах достаточно большого размера.

Ты же, как я понимаю, в основном работаешь по фиксированному адресу в верхней части памяти, т.к. оставляешь для образа буфер определенного размера. Получается примерно такая картина:
ivt bda z образ [zzzzzz] "все твое добро"
Я же использую начало памяти:
ivt bda "все мое добро"* образ [zzzzzz]**
* Если места для моего добра более чем достаточно, то обычно локализую его местоположение под базой образа, а стек будет расти вниз в незадействованную память.
** Это для общей картины. Память, начиная с этого участка, я уже не использую.

1) Не сложней, а легче;
2) Да, при большом резерве размер страдает. Хотя у такого резерва есть и множество преимуществ, о чем когда-то говорили. Я полностью признаю твои заслуги в плане возможности загружать образ большего размера, чем это возможно у меня. Хотя я говорил, какие изменения тебе можно сделать не в ущерб размеру твоего образа.

Использовать оптимальный порядок действий в плане замещения одного кода другим.

Может, прекратим разговоры про лучший вариант организации памяти, а то мы безрезультатно бьемся в стенку с разных сторон? Ты добавил описание памяти, которую гарантированно можно использовать в ядре без проверки?

Я вообще пэйджинг совместно с IVT не использую В ядрах под Pentium я делал первую физ. страницу некэшируемой и размещал в ее конце начало IDT, естественно, переотображая ее в пространство ядра. В ядрах под современные процы я эту страницу или вообще не использую, или использую наравне со всеми. Данные BDA после отключения тождественного отображения уже не используются. Размер начального стека ядра я контролирую.

Про сторонний софт я говорил.

Я про номер версии.

Вот я так и понял, ты придерживаешься той же идеологии, - структура в ущерб гибкости. Извини, значит, у нас идеологические разногласия.


Я просто не вижу в них никакой необходимости.


Ни ты, ни я пока не знаем, что там будет возможно, а что нет. Далеко не всегда можно сделать код вытесняемым. Во-первых размер кода растёт не только из-за разбора структуры, но и из-за обилия вспомогательных функций, которые требуются там и сям. Во-вторых, не забываем о том, что расти может не только код, но и рабочие области данных.


Не, т.к. пакет уже опубликован, нехорошо его постоянно перепаковывать. Описание будет в следующей версии (до неё не так далеко, сейчас интервалы будут поменьше), а сейчас достаточно будет сказать, что гарантировано наличие 628к ОЗУ, таким образом, можно без опаски устанавливать стек, например, так:



Т.е., назвать 103 версией?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Это точно! Да и гибкость мы понимаем немного по-разному.

Ну-ну, т.е. народ должен вчитываться в наш диспут. Не хочешь опубликовать разъяснение на сайте?

А вообще спеки можно хранить отдельно и давать ссылки на них.

Ну, если это твоя новая система присвоения версий, то можно и так. Хотя прежде я наблюдал другой порядок. Тебе типа лень и ты решил поприкалываться? Или ты реально не знаешь другого лексического значения слова "сотка", кроме как обозначения числа 100?

Я же сказал, разъяснения будут в следующей версии. Сейчас всего два-три пользователя пакета, для них не проблема разобраться. Да и разъяснять там особо нечего.
Кстати, посчитал ещё раз...
...какие 8к? Все загрузчики ютятся в 6.5к!!! Где ты ещё найдёшь такие "утрамбованные" загрузчики даже под жёсткие файловые системы? Всё отдано на благо пользователя, а меня и с этими крохами хотят поджать, как будто это так легко. Гораздо легче тебе поставить джамп и добить его нулями до базы 800h, если тебе это так важно.
На этом предлагаю закончить обсуждение базы загрузки.


Не прикалываюсь. Если ты имеешь ввиду нумерацию из трёх групп, типа 3.0.1, то да, такая нумерация будет введена. Младшая группа под баг-фиксы, средняя под добавление фич, старшая под радикальные обновления.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>