Board.KolibriOS.org

art_zh wrote:А потом понял, что это была его твердая позиция - оставить Колибри "не только очень быстрой, но еще и очень маленькой системой". Можно с этой позицией спорить, можно ее разделять или отвергать, но учитывать ее нужно в любом случае.

Так лично я за, но ведь для этого же и есть 1.44 floppy image.
Но те люди, которые хотят использовать Колибри как свою основную (или даже единственную) операционную систему, не могут себя ограничить 1.44 мегабайтами - им же нужен и flpay, и возможно quake, dosbox, место для фильмов и т.д. - и для удобства это всё должно определяться Колибри как один раздел диска.

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)

Mario wrote:yogev_ezra
А кто мешает использовать раздел с Колибри и располагать большие программы там? Все-же рамдиск дает огромное преимущество для ускорения запуска основных компонентов.

Я согласен, но для таких проектов, как Embedded, жёсткое ограничение на 1.44 мегабайта в размере рамдиска по-моему очень мешает. Я сегодня не вижу даже Embedded систем с менее, чем 128 мегабайт памяти, так если увеличить рамдиск с 1.44 мегабайта до, скажем, 32 мегабайта, от них не убудет.

А если мы говорим о помещении рамдиска полностью в L2 CPU cache, так для Embedded систем 1.44 мегабайта это уже много, потому что большинство их имеет L2 cache 256Kb - 512Kb.

Spoiler:

Анекдот в тему:
- Один волос - это много, или мало?
- Ну, это смотря где: один волос на голове - это очень мало, а один волос в супе - это уже много

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. Количество мусора, надо заметить, зашкаливает. Чего стоит только

рекомендую еще попробовать -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/.