"Ночные" сборки KolibriOS

Share your distros and discuss others'
  • shurf wrote:
    yogev_ezra wrote:Вроде бы здесь и здесь писали, что теоретически 2.88Мб можно, и вот это что за файл?
    Да, я попытался такое сделать. Максимум чего добился - это загрузки с такого образа ядра kernel.mnt.
    А далее понял, что места в карте памяти для загрузки образа диска не хватает, и двигать границы
    разделов не решился.
    Раздвигать рамки не нужно - нужно придумать как загрузить образ в участок, который потом не должен использовать менеджер памяти. Сам код работы с рамдиском доработать не сложно, проблема именно в согласовании с менеджером памяти.

    yogev_ezra
    А кто мешает использовать раздел с Колибри и располагать большие программы там? Все-же рамдиск дает огромное преимущество для ускорения запуска основных компонентов.
  • Yes, the floppy-ramdisk should not be enhanced, but removed and replaced with a 'real' ramdisk.

    For embedded systems like the eBox, I think it's even better not to use ramdisk at all.
    (And use flash memory for all programs)
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • Mario wrote:yogev_ezra
    А кто мешает использовать раздел с Колибри и располагать большие программы там? Все-же рамдиск дает огромное преимущество для ускорения запуска основных компонентов.
    Я согласен, но для таких проектов, как Embedded, жёсткое ограничение на 1.44 мегабайта в размере рамдиска по-моему очень мешает. Я сегодня не вижу даже Embedded систем с менее, чем 128 мегабайт памяти, так если увеличить рамдиск с 1.44 мегабайта до, скажем, 32 мегабайта, от них не убудет.

    А если мы говорим о помещении рамдиска полностью в L2 CPU cache, так для Embedded систем 1.44 мегабайта это уже много, потому что большинство их имеет L2 cache 256Kb - 512Kb.
    Spoiler:Анекдот в тему:
    - Один волос - это много, или мало?
    - Ну, это смотря где: один волос на голове - это очень мало, а один волос в супе - это уже много :lol:
    hidnplayr wrote:For embedded systems like the eBox, I think it's even better not to use ramdisk at all.
    (And use flash memory for all programs)
    Why, I think ramdisk is good everywhere, and even better in eBox, since it can speed things up. But L2 cache in eBox is only 256Kb so maybe a small ramdisk is good.
  • yogev_ezra
    Я не подразумевал использование кеша процессора, однако уже само размещение файлов на рамдиске в десятки, если не сотни, раз ускоряет доступ к ним. На современных системах достаточно памяти ОЗУ для содержания рамдиска.

    Естественно вариант системы совсем без рамдиска тоже должен присутствовать. Как правильно заметил hidnplayr - на системах использующих flash память вполне можно обойтись и без него.

    Однако есть ряд проблем которые могут проявиться. На сегодня доступ к файловой системе (не считая рамдиска) реализован как монопольный и никакой псевдо-параллельности нет. Если одно приложение займет доступ к системному ресурсу и подвиснет, все остальное подвиснет также - невозможно будет даже запустить CPU чтобы прибить зависшее приложение. Об этом уже вопрос поднимался больше года назад -именно потому Diamond был против отказа от рамдиска.

    Эту тему я уже прокручиваю в голове не менее 2-х лет. Нужна "прозрачная" для приложений реализация псевдо-параллельности обработки запросов к файловой системе. Разбиение запросов большого объема на меньше, например множество 16-128 Кб, вместо одиночного на мегабайты или даже гигабайт. Это может сказаться на падении производительности файловой системы, поскольку в свое время я так и не смог реализовать полностью динамический файловый кеш с использованием хэширования для поиска уже загруженных секторов.

    Однако относительно текущей системы я думаю падение производительности на 10-20% не критично, относительно решения проблемы продолжительного монопольного доступа к файловым ресурсам.
  • В последнем компиляторе gcc 4.5 появилась Link-Time Optimization, способная учитывать взаимодействие функций из разных файлов исходного кода - то, что у Microsoft называется Link-Time Code Generation и появилось, кажется, ещё в 2003-й студии. В связи с этим в дополнение к win32-gcc - который mingw'шный бинарник 3.4.5, запускаемый через wine, - теперь на сервере есть win32-gcc45 - который не mingw'шный бинарник, потому что на mingw.org про LTO не знают. Я также перевела сборку самого большого по размеру файла - atikms.dll - на gcc45 чуть не стерев зубную эмаль от того, что единственный способ получить информацию о включении -mpush-args - это посмотреть в исходный код компилятора, что сократило упакованный бинарник на ~10K, частично скомпенсировав его же рост в r1871 на ~2K. Количество мусора, надо заметить, зашкаливает. Чего стоит только

    Code: Select all

    .text:000033EA                 movzx   edx, byte ptr [eax+ebx+3]
    .text:000033EF                 shl     edx, 8
    .text:000033F2                 movzx   esi, byte ptr [eax+ebx+2]
    .text:000033F7                 or      esi, edx
    .text:000033F9                 shl     esi, 10h
    .text:000033FC                 movzx   edx, byte ptr [eax+ebx+1]
    .text:00003401                 shl     edx, 8
    .text:00003404                 movzx   eax, byte ptr [eax+ebx]
    .text:00003408                 or      eax, edx
    .text:0000340A                 movzx   eax, ax
    .text:0000340D                 or      esi, eax
    
    Сделаем мир лучше!
  • рекомендую еще попробовать -fwhole-program
  • XVilka, -fwhole-program включено.
  • Сегодня проверял, загрузочный iso прекрасно создаётся mkisofs с ключами -U -J -iso-level 3. Колибри поддерживает путь /sys/, на который монтируется /rd/1/. Если после загрузки ядра переписать /sys/ путём к загрузочному cd, дистрибутив будет работать со всеми программами с компакт диска без всяких шаманских камланий. Надо только определиться со структурой каталогов.
  • Хорошая новость. Значит, кроме floppy можно теперь и cd-версии собирать.

    Мое личное субъективное мнение:
    Spoiler:в live cd версию ночных сборок не стоит запихивать всё, что есть (хотя его не очень-то и много). Образ более 3-5 мегабайт для меня, например, скачивать не очень удобно, а в 20 мегабайт (потенциальную свеженькую ночную сборку) - совершенно нереально.
  • Serge wrote:Если после загрузки ядра переписать /sys/ путём к загрузочному cd, дистрибутив будет работать со всеми программами с компакт диска без всяких шаманских камланий.
    Не считая того что нужно отследить все программы использующие /rd/1/ для обращения к системному диску, а так да - работает как задумывалось еще несколько лет назад.
  • Mario

    Так ведь /rd никуда не денется. В самом простом варианте /cd должен содержать копию файлов /rd.
  • Serge
    Так можно получить коллизии при невнимательном составлении диска. В память RD загружается из области загрузчика, а на CD другая директория с копиями файлов.
    К тому же ядро после загрузки не знает откуда оно было загружено - остается озадачивать пользователя.

    З.Ы. Тот же ALT Linux с CD стартует при помощи ISO Linux.
  • Serge, я не понимаю, какой должен быть загрузчик на таком CD, а также верно ли, что /sys планируется сделать ярлыком на /cdX - и если да, то что планируется сделать с проблемой тормозов в некоторых эмуляторах при запуске каждой программы с CD, что, несомненно, будет сильнейшим образом влиять на мнение пользователей, проверяющих интересные ОС на эмуляторах.
    Сделаем мир лучше!
  • Для справки: на сервере сборки mkisofs уже есть, так что можно добавлять конкретные действия с его участием в data/*/Makefile. Система сборки в текущем виде не станет выкладывать ничего рядом с svn*-img.7z, но скопирует все - включая неизвестные - файлы из рабочей папки в svn*-data/ и, в частности, svn*-data/build/.
    Сделаем мир лучше!
  • Who is online

    Users browsing this forum: No registered users and 2 guests