Board.KolibriOS.org

to Serge
1) Не считаю что загрузку ОС нужно жестко привязывать к GRUB загрзузчику. GRUB есть не на всех машинах. К примеру если нужно быстро сделать загрузку с раздела NTFS, где установлена Win, можно сделать типа mtldr, им грузить вторичный загрузчик, а он уже будет обрабатывать ini файлы и формировать ramdisk, загружать модули и в конце передаст управление ОС. Проблема в согласовании загрузки Grub и вторичного загрузчика. Более предпочтительный вариант и на мой взгляд универсальный - это загрузка Grub вторичного загрузчика.

<Lrz>

К примеру если нужно быстро сделать загрузку с раздела NTFS, где установлена Win, можно сделать типа mtldr, им грузить вторичный загрузчик, а он уже будет обрабатывать ini файлы и формировать ramdisk, загружать модули и в конче передаст управление ОС

То есть для начала напишем свой собственный GRUB. Что-то похожее я предлагал два года назад в начале этой ветки. (viewtopic.php?p=5416#p5416 Очень интересное обсуждение. Новое - слегка забытое старое ? ) И даже отделил 16-ти битный загрузчик от ядра. Блин ! Я тогда не был знаком с GRUB. Не стоит повторять мои ошибки.

GRUB не обязательно ставить на машину. Достаточно сделать загрузочную флешку или СD и прописать путь к ядру. GRUB-2 умеет загружaть и со сжатых NTFS.

В таком случае нужно отказаться от загрузки чрез "blue screen" и полность перейти на загрузку GRUB. Но вот что бы загрузить ОС без GRUB, понадобиться шаманство. Либо делать загрузку GRUB и переделать blue screen так, что бы можно было загрузиться и без GRUB. GRUB может сделать ramdisk? Кто будет делать ramdisk?

<Lrz>

А каким должен быть рамдиск? И нужен ли вообще ? Одним из аргументов в пользу рамдиска в Колибри было то, что с него можно загрузить cpu или end если зависнет дисковая подсистема. Вообще-то их можно включить в ядро как бинарники и запускать прямо из памяти.

ИМХО нынешний рамдиск-образ дискеты себя изжил. Значит нет необходимости запихивать на рамдиск весь дистрибутив. Достаточно держать там несколько ключевых программ.

GRUB может загрузить файлы из которых код инициализации ядра соберёт рамдиск. Не обязательно FAT12. Любая простейшая ramfs с доступом только на чтение. Это не мешает сделать полноценный большой рамдиск и примонтировать его /temp/

Из всего загрузочного экрана нужен только выбор видеорежима и тот можно устанавливать через GRUB. -vrr -biosdisk пойдут как опции в командной строке. Хотя vrr уже не будет.

Считаю, что нужен. Он создает проблему?
Вообще его нужно воспринимать как законченную систему (минималистичную) или даже как ядро.
Всегда под рукой есть средства (отладка и прочие мелочи по изменению корней системы) получить доступ к FAT12/16/32, но вот до того же initrd (а это ramdisk) достучаться уже сложнее. Т.е. от чего сейчас уйдем, к тому и прийдем.

..bw

А как планируется поступить с сетью?
Останется в ядре, перейдёт в user-mode или в api.dll?

Все сервисы надо убирать из ядра. Так что это будет или сервис в user mode или сервис в пространстве ядра. Пока не ясно, но в ядре никаких служб не останется. Api.dll условное название прослойки для вызовов ядра и основных сервисов (файловая система, сеть и т.п)
Например api преобразует posix вызов ssize_t read (int filedes, void *buffer, size_t size) в IPC и отправит его vfs, получит ответ, установит errno и вернёт результат. При этом внутренняя реализация вызова ipc может меняться в каждой версии, а posix функция уже не изменится.

Serge
Означает ли твои изменения, что после них, смысл написания кода на ассемблере будет потерян ? Т.е. после изменений большая часть кода будет писаться на С, поскольку это сделать будет наиболее проще. Т.е. можно уже говорить что проект не будет в дальнейшем являться Асм проектом?

Чтобы упростить совместную разработку на С и АСМ предлагаю обсудить эти правила.

Вызываемая функция должна сохранять регистры EBX,EDI,ESI,ESP,EBP и флаг направления DF регистра EFLAGS

Функции с одним или двумя параметрами используют соглашение gcc fastcall: первый аргумент передаётся в ECX второй в EDX

Функции с числом параметров больше двух используют соглашение cdecl: параметры передаются через стек в обратном порядке, вызывающая функция очищает стек.

<Lrz>

Не означает. Если кому-то нравится писать на ассемблере то api.dll не помешает. Программировать IPC на асме ещё сложнее чем на С, достаточно посмотреть на minix.
Но проект не будет асм в чистом виде. Он уже не чистый асм. Моё мнение - надо подготовить ядро и отработать микроядерные механизмы и SMP чтобы потом перенести это на 64 бита. Это проще сделать на С. И уже потом заняться доводкой кода. Тратить время на разработку новой супер-пупер 32-х битной системы на чистом асм у меня нет никакого желания потому что почти весь этот код придётся переписывать. Вы ведь новую ось пишете сразу под 64 бита ?
Конечное соотношение асм и С будет зависить от разработчиков.

Соглашение с С, типа stdcall or cdecl на 32 битной платформе, в достаточной мере урезает возможности для написания кода на асме. Т.е для каждого вызова нужно делать дополнительную обертку к существующему коду. Это приведет к увеличению кода (это не принципиально как говориться + или - несколько мегобайт погоду не сделают). Уменьшения производительности (и тут + или - 1000 тактов погоду не сделают).
Да, можно доводить функции до совершенства получая С-ый листинг и перерабатывая его. Это очень производительно и эффективно.

ИМХО если отбрасывать все старое то нужно изначально ориентироваться на х64. Его возможности очень широки.

>Вы ведь новую ось пишете сразу под 64 бита ?
Как я тебе говорил, некоторые люди проводят исследование в данной области, да будет поддержка только х64, и весь код будет оптимизироваться под х64 набор инструкций и возможностей.

<Lrz>

для каждого вызова нужно делать дополнительную обертку к существующему коду

К существующему да. Неизбежное зло. Не надо делать обёртки для нового кода. По поводу скорости и эффективности асм - pushad встречается в kernel.asm 21 раз, в window.inc 19 раз. Всего 140 раз. Потому что нет никаких соглашений.

Пожалуйста дай ссылку на описание GRUB загрузчика, желательно на русском.
Если будет возможно уберу blue screen и код use 16 в отдельный модуль.

http://www.gnu.org/software/grub

Официальные
http://www.gnu.org/software/grub/manual
http://www.gnu.org/software/grub/manual/multiboot

Очень старая версия на русском
http://gazette.linux.ru.net/lg64/articl ... kohli.html

Сделал загрузку GRUB-ом.

Примерное меню:

title Kolibri
root (hd0,1)
kernel --type=multiboot /kos/kernel.mnt
module /kos/kolibri.img

Образ дискеты грузится как модуль, без него работать не будет. Настройки не сохраняются и нет рестарта ядра. В остальном без изменений.