mnt -> img, сборка проекта

Internal structure and you change requests/suggestions
  • kernel.mnt - ядро
    *.obj - драйверы и библиотеки.
    kolibri.img - образ IMG дискеты

    Linux - mount
    Windows - ImDisk Virtual Disk Driver

    Под самой Колибри есть утилита RDSAVE, которая записывает содержимое текущего рамдиска куда укажет пользователь.

    Сервер автосборок собирает из исходников готовые образы, поднять такое можно у себя на Linux (как поднять не скажу, так как не задавался такой задачей), но гораздо проще закинуть ядро и драйвера в готовый IMG образ дискеты.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote: ...
    Linux - mount
    Windows - ImDisk Virtual Disk Driver
    На сколько я знаю, эти утилиты получают на вход уже готовый *.img и преобразуют его в виртуальное устройство или что-то ещё. Или это не так?
  • cadabr wrote:На сколько я знаю, эти утилиты получают на вход уже готовый *.img и преобразуют его в виртуальное устройство или что-то ещё. Или это не так?
    Если вопрос был "Как вручную создать kolibri.img из всех файлов?", то в Windows - WinImage (она платная, но можно скачать Shareware на 30 дней), а в Linux:

    Code: Select all

    dd if=/dev/zero of=build/kolibri.img count=2880 bs=512 2>&1
    dd if=build/boot_fat12.bin of=build/kolibri.img count=1 bs=512 conv=notrunc 2>&1
    и далее, по скрипту, mmd и mcopy
    Но так как обычно за один раз меняется только один исполняемый файл (например, ядро kernel.mnt), то проще всего открыть существующий файл kolibri.img с помощью WinImage, и просто заменить один файл и сохранить. Я так делаю - очень удобно.
  • Зачем создавать новый, когда можно просто так взять и удалить в старом все файлы, и сохранить. Будет пустой файл.
    Не рекомендую пользоваться WinImage по двум причинам:
    1) платный, а воровать все же нехорошо.
    2) на N-ное открытие/сохранение IMG образа он создает в его файловой системе необъяснимые "глюки".
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • cadabr wrote:На сколько я знаю, эти утилиты получают на вход уже готовый *.img и преобразуют его в виртуальное устройство или что-то ещё. Или это не так?
    Да, но пустой отформатированный образ получить значительно проще. Потом ты его монтируешь, выполняешь файловые операции, после чего размонтируешь. Есть утилиты, которые позволяют напрямую (без монтирования) выполнять файловые операции внутри образа, например, mtools. Я помимо спец. утилит всегда использовал fasm для формирования образа с файлами и каталогами, причем исходные файлы могли находиться в разных местах, т.е. их не нужно предварительно собирать в какой-то определенной папке. Примеры использования можно поискать на forum.osdev.org по ключику mkfloppy. Я пока прикрыл эти исходники, т.к. в них жестко закодирована обычная разметка ФС для флоппиков 1,44 мб и используется старый стиль описания структуры каталогов. Могу опубликовать на время старые исходники, но не хотелось бы, т.к. сейчас я четко вижу их несовершенство. Новый стиль описания структуры каталогов значительно удобнее и нагляднее (посмотреть образец можно здесь), но работа над новой версией еще не завершена. Если у кого-то есть желание потом потестить новую версию, я могу оставлять ссылки здесь.
  • yogev_ezra wrote:и далее, по скрипту, mmd и mcopy
    Спасибо, чтение этого лога проясняет. Но оказалось что, сборка проекта в локальной копии проекта без дополнительных усилий затруднительна. В логе видно, что файлы, копируемые в образ, разбросаны по многим директориям.
    Phantom-84 wrote:причем исходные файлы могли находиться в разных местах, т.е. их не нужно предварительно собирать в какой-то определенной папке. Примеры использования можно поискать на forum.osdev.org по ключику mkfloppy.
    Обязательно изучу этот форум, но нельзя ли от вас услышать немного вводной информации по этому поводу?
    Таким образом тема ветки плавно переходит к вопросу сборки проекта. Я правильно понял, что сейчас в репозитории нет средства для сборки такой же, какую выполняет сборочная машина?
  • cadabr wrote:Таким образом тема ветки плавно переходит к вопросу сборки проекта. Я правильно понял, что сейчас в репозитории нет средства для сборки такой же, какую выполняет сборочная машина?
    Нет, поскольку не возникало такой необходимости. Разработчики обычно работают с одной программой в единицу времени. Максимум еще могут править код библиотеки. Соответственно забросить изменения в образ не составляет проблемы. Обычные же пользователи пользуются готовой бинарной сборкой. Вам хочется "странного", потому вы будете вынуждены сами решать этот вопрос.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • cadabr wrote:Спасибо, чтение этого лога проясняет. Но оказалось что, сборка проекта в локальной копии проекта без дополнительных усилий затруднительна. В логе видно, что файлы, копируемые в образ, разбросаны по многим директориям.
    А как вы хотели? В образ входит множество файлов, которые логически распределены по разным папкам, причем как перед сборкой образа, так и после, т.е. внутри него.
    Обязательно изучу этот форум, но нельзя ли от вас услышать немного вводной информации по этому поводу?
    Можно. Вместо сборочного скрипта используется исходник на fasm'е, описывающий размещение файлов и папок внутри образа и то, откуда можно взять исходные файлы.

    Edited.
    В репозитории сценарии build.bat и makefile строят kernel.mnt и ещё несколько файлов в папке bin
    Ммм... Из ядра и драйверов вы не сможете получить нормально работающую систему. Определитесь сначала, нужен ли вам загрузочный образ с ядром или же с полноценной системой.
  • Phantom-84 wrote:А как вы хотели? В образ входит множество файлов, которые логически распределены по разным папкам, причем как перед сборкой образа, так и после, т.е. внутри него.
    Судя по логу, сборочный сценарий выполняется в окружении структуры файлов иной, чем в репозитории. Взять примеру (далее выдержки из логов сборки)

    Code: Select all

    mcopy -moi build/kolibri.img @clip ::@CLIP
    такого файла не нашёл в репозитории.

    Code: Select all

    mcopy -moi build/kolibri.img @menu ::@MENU
    есть только в programs/bin/

    Code: Select all

    mcopy -moi build/kolibri.img File\ Managers/icons.bmp ::File\ Managers/ICONS.BMP
    директория File Managers есть только в data/rus (ну или eng и тд) но файл icons.bmp лежит совершенно в другом месте. В какой директории не запускай указанные три команды, они корректно не выполнятся.
    Я это всё к чему: обычно когда скачиваю какой-нибудь проект, одним из первых действий всегда знакомлюсь со сценариями сборки, и только потом приступаю к глубокому изучению кода, вдруг где-то что-то захочется "пошевелить" чтобы посмотреть, как это отразится в рантайме, тут уже нужно уметь осмысленно запускать сборку. С Колибри оказалось не так. Я так понял, что скрипт существует, но он не в паблике.
    Определитесь сначала, нужен ли вам загрузочный образ с ядром или же с полноценной системой.
    Тут я в затруднении ввиду того, что новичок, и ещё не освоился с проектом. Как протестировать только что внесённые изменения в ядро? Перестроить kolibri.mnt и обновить внутри kolibri.img? Значит целиком kolibri.img собирается только на сервере?
  • cadabr wrote:Судя по логу, сборочный сценарий выполняется в окружении структуры файлов иной, чем в репозитории. Взять примеру (далее выдержки из логов сборки)

    Code: Select all

    mcopy -moi build/kolibri.img @clip ::@CLIP
    такого файла не нашёл в репозитории.
    Физически репозиторий SVN и скрипт автосборки находятся на одном и том же сервере в разных директориях. Поэтому скрипт автосборки имеет доступ ко всем файлам репозитория. @CLIP находится в репозитории, он берётся из пути, указанного в Makefile (который тоже находится в репозитории и собственно, содержит почти весь скрипт автосборки).

    Code: Select all

    PROGS:=$(REPOSITORY)/programs
    ...
    FASM_PROGRAMS:=\
     @clip:@CLIP:$(PROGS)/system/clip/trunk/@clip.ASM \
    итого, /programs/system/clip/trunk/@clip.ASM
    cadabr wrote:Я это всё к чему: обычно когда скачиваю какой-нибудь проект, одним из первых действий всегда знакомлюсь со сценариями сборки, и только потом приступаю к глубокому изучению кода, вдруг где-то что-то захочется "пошевелить" чтобы посмотреть, как это отразится в рантайме, тут уже нужно уметь осмысленно запускать сборку. С Колибри оказалось не так. Я так понял, что скрипт существует, но он не в паблике.
    Ну почему же? Makefile (линк на который я дал выше) и почти все другие файлы автосборки находятся в репозитории в директории /data.
    cadabr wrote:Как протестировать только что внесённые изменения в ядро? Перестроить kolibri.mnt и обновить внутри kolibri.img?
    Да, так проще всего.
    cadabr wrote:Значит целиком kolibri.img собирается только на сервере?
    На сегодняшний момент, да, но не потому, что это невозможно, а потому, что это никому не нужно.
    Если Вам нужно, то Вы можете воспользоваться скриптами из директории /data, слегка изменив их.
  • cadabr wrote:Судя по логу, сборочный сценарий выполняется в окружении структуры файлов иной, чем в репозитории. Взять примеру (далее выдержки из логов сборки)

    Code: Select all

    mcopy -moi build/kolibri.img @clip ::@CLIP
    такого файла не нашёл в репозитории.

    Code: Select all

    mcopy -moi build/kolibri.img @menu ::@MENU
    есть только в programs/bin/

    Code: Select all

    mcopy -moi build/kolibri.img File\ Managers/icons.bmp ::File\ Managers/ICONS.BMP
    директория File Managers есть только в data/rus (ну или eng и тд) но файл icons.bmp лежит совершенно в другом месте. В какой директории не запускай указанные три команды, они корректно не выполнятся.
    Я это всё к чему: обычно когда скачиваю какой-нибудь проект, одним из первых действий всегда знакомлюсь со сценариями сборки, и только потом приступаю к глубокому изучению кода, вдруг где-то что-то захочется "пошевелить" чтобы посмотреть, как это отразится в рантайме, тут уже нужно уметь осмысленно запускать сборку. С Колибри оказалось не так. Я так понял, что скрипт существует, но он не в паблике.
    Перед сборкой образа выполняется предкомпиляция всех (или по крайней мере большинства) исполняемых файлов и сбор всех (или по крайней мере большинства) файлов данных в отдельной папке. Тебе посоветовали обеспокоиться подготовкой соответствующего скрипта самостоятельно (ну, или можешь попытаться попросить уже готовый). Сборка проекта (программы или комплекта программ) и сборка всего, что включается в дистр. образ ОС, с последующей сборкой самого образа - это немного разные вещи. Обычно в последнем случае значительно проще подключать нужные компоненты и отключать ненужные. Можешь попробовать собрать свой дистрибутив Колибри.
    Тут я в затруднении ввиду того, что новичок, и ещё не освоился с проектом. Как протестировать только что внесённые изменения в ядро? Перестроить kolibri.mnt и обновить внутри kolibri.img? Значит целиком kolibri.img собирается только на сервере?
    Зависит от того, что именно ты собираешься тестировать в ядре. Тебе точно не нужен полный дистрибутив. А часто вообще достаточно минимального комплекта. Помимо самого ядра и всего того, что ему нужно для нормальной работы, это обычно несколько утилит и несколько тестовых программ.
  • @clip вообще нужно закопать уже, это попытка реализации буфера обмена исключительно для текстовой информации дурным методом. Хромал и полноценно не работал, потому я его убрал из автосборки. Реализация функции буфера обмена в ядре полностью снимет вопрос, но у меня в сутках только 25 часов, а еще летом я строю дом.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • yogev_ezra wrote:Ну почему же? Makefile (линк на который я дал выше) и почти все другие файлы автосборки находятся в репозитории в директории /data.
    Прояснилось! Большое спасибо!
  • yogev_ezra wrote: то проще всего открыть существующий файл kolibri.img с помощью WinImage, и просто заменить один файл и сохранить. Я так делаю - очень удобно.
    Mario_r4 wrote:Не рекомендую пользоваться WinImage
    Virtual Floppy Drive 2.1 - по функциональности похож на ImDisk Virtual Disk Driver.
    Монтирует имеющийся .img фаил как виртуальную дискетту или создает такой.
    Spoiler:Инструкция:
    Скачать, рапаковать, в папке запустить "vfdwin.exe".
    В открывшемся окне в вкладке Driver нажать на Start.
    111.jpg
    111.jpg (32.2 KiB)
    Viewed 11089 times
    В вкладке Driver1 (или Driver0) нажать на Change и дать название дискетте
    222.jpg
    222.jpg (36.38 KiB)
    Viewed 11089 times
    Нажав на Open/Create... Нужно выбрать где будет лежать .img фаил и дать ему название или выбрать уже существующий
    .img фаил. Или ничего не выбрав сначала работать как с RAM диком а потом сохранить.
    333.jpg
    333.jpg (45.73 KiB)
    Viewed 11089 times
    Дискетта открывается также и тамже где и все остальные диски
  • Who is online

    Users browsing this forum: No registered users and 2 guests