Board.KolibriOS.org

Mario_r4
1. UUID - строка в hex формате, какие там ограничения на символы ?
2. свой UUID для разных дистрибутивов не проблема автоматом генерировать во время сборки.
3. IMHO лучше разделять /rd/1/ и /sys. /rd/1/ сохранить как аналог /boot для ядра, драйверов и программ без которых система не работает.

Где-то есть ограничения 8.3. UUID не поместится.

Меня мучает вопрос - как генерировать UUID. Желательно, чтобы была возможность во всех средах (Win/Linux/Kolibri) получать одинаковые результаты.

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

Гм. Либо предусмотреть три метки:

• Системная, работающая по умолчанию.
• Пользовательская, перебивающая системную.
• Пользовательская, дополняющая системную.

Mario_r4
Утилит и исходников для генерации в сети много.
Собственно почему я предлагаю UUID и монтирование на /sys.

Для каждой языковой версии дистрибутива можно сделать свой UUID. Это упростит проверку установщиком и версии дистрибутива и языка установки.

Подмена /sys уже реализована в ядре. Добавление ещё одной папки сделает довольно запутанный код ещё сложнее.

Serge wrote:Утилит и исходников для генерации в сети много.

Раньше посылали... далеко в общем, а теперь в гугл.
Собственно у меня идея делать для каждой ревизии свой UUID. В том числе генерация в самой Колибри нужна.

Serge wrote:Подмена /sys уже реализована в ядре. Добавление ещё одной папки сделает довольно запутанный код ещё сложнее.

Если так рассуждать, то любая последующая ревизия вообще делает код еще сложней и запутанней. Между тем грузить ВСЕ файлы с CD/DVD очевидно не выгодно в плане скорости.

Mario_r4
CD/DVD должны проверяться в последнюю очередь.

Собственно у меня идея делать для каждой ревизии свой UUID. В том числе генерация в самой Колибри нужна

Сделать подмену макросом, как для svn:revision, а генерировать на сервере автосборок.

нужный раздел, с нужным контрольным файлом

пустой файл с именем - UUID строкой

Не совсем понял необходимость этого.

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

Это должна делать программа-установщик(как это и происходит в других ос).
Как сказал Mario_r4, нужна SysFn, которая умеет монтировать разделы(и не важно, что это за разделы). Тогда в autorun.dat можно написать что-то вроде: mount "/addappl".
Если нужна ещё и установка чего-то, то добавить: /addappl/install.kex.

Я думаю копирование их на темповский диск не всегда оправдано

Между тем грузить ВСЕ файлы с CD/DVD очевидно не выгодно в плане скорости

В любом случае изначально файлы находятся на CD/DVD, значит, всё равно какие-то из них нужно копировать на tmp. Этим и будет заниматься install.kex:
если нет tmp, то создать, скопировать нужные файлы, установить ассоциации и т.п.
если не получилось создать нужного размера tmp, то не копировать и установить другие ассоциации...

0CodErr wrote:Не совсем понял необходимость этого.

Система после загрузки знает только о наличии /rd/1, о наличии других мест где можно брать программы, бибилотеки, данные - она не знает. Нельзя жестко прописать запуск видеоплеера, к примеру с /cd0/1/ потому что нельзя гарантировать его наличие именно по этому пути. Метка позволяет просмотрев все известные диски и разделы найти нужный. Теперь достаточно понятно?

0CodErr wrote:Это должна делать программа-установщик(как это и происходит в других ос).

Подразумевался запуск Live системы.

0CodErr wrote:Как сказал Mario_r4, нужна SysFn, которая умеет монтировать разделы(и не важно, что это за разделы). Тогда в autorun.dat можно написать что-то вроде: mount "/addappl".
Если нужна ещё и установка чего-то, то добавить: /addappl/install.kex.

Я не готов писать полноценный mount, да и для озвученной в теме идеи он не нужен.

0CodErr wrote:В любом случае изначально файлы находятся на CD/DVD, значит, всё равно какие-то из них нужно копировать на tmp. Этим и будет заниматься install.kex:

Еще раз - речь идет о Live системе и к моменту запуска у нас уже есть /rd/1/ с файлами. Загружать их не нужно, совсем не нужно.

З.Ы. У меня создалось впечатление что ты не понял тему. Хотя речь идет о Live системе, возможность найти собственный раздел будет полезна и уже установленной системе. Пользователь может переподключить диск на другой контроллер, воткнуть еще одну флешку, кроме загрузочной и т.д.

Serge wrote:Сделать подмену макросом, как для svn:revision, а генерировать на сервере автосборок.

А если пользователь желает сам собрать свой дистрибутив - ему что теперь UUID генерировать руками?

З.Ы. У меня создалось впечатление что ты не понял тему.

Да, возможно, не совсем.

Я не готов писать полноценный mount, да и для озвученной в теме идеи он не нужен.

Но монтировать раздел всё равно нужно и новая SysFn?

Нельзя жестко прописать запуск видеоплеера, к примеру с /cd0/1/ потому что нельзя гарантировать его наличие именно по этому пути.

С одной стороны жёстко вообще ничего нельзя прописать(плееры могут быть разные, набор программ различаться). Но с другой стороны в конкретном дистрибутиве конкретный набор программ. Если прописать "/addappl/FPlay/fplay.kex", то, если плеер там будет, он запустится. Поэтому, если плеер у нас на cd\dvd, то нужно этот диск монтировать в "/addappl".

Система после загрузки знает только о наличии /rd/1, о наличии других мест где можно брать программы, бибилотеки, данные - она не знает.

Пользователь может переподключить диск на другой контроллер, воткнуть еще одну флешку, кроме загрузочной и т.д.

Ядро ведь сейчас и так монтирует диски\флешки? А самому ядру для работы не нужно никаких программ.

Метка позволяет просмотрев все известные диски и разделы найти нужный.

Этот поиск будет происходить один раз при старте или постоянно во время работы?
Ведь при переподключении диск отмонтируется и нужно будет снова его монтировать.

Почему вместо UUID нельзя использовать текстовый файл с содержанием <номер версии>+<номер ревизии>+<язык>+<опциональный текст для пользователя "этот файл служит для идентификации раздела /addappl или как его там"? Кажется, это более понятно для конечного пользователя.

0CodErr wrote:Но монтировать раздел всё равно нужно и новая SysFn?

Я пока склоняюсь к предложению Serge - сделать код исключительно в ядре и он отработает до запуска приложения Launcher.

0CodErr wrote:С одной стороны жёстко вообще ничего нельзя прописать(плееры могут быть разные, набор программ различаться). Но с другой стороны в конкретном дистрибутиве конкретный набор программ. Если прописать "/addappl/FPlay/fplay.kex", то, если плеер там будет, он запустится. Поэтому, если плеер у нас на cd\dvd, то нужно этот диск монтировать в "/addappl".

Содержимое меню определяется его составителем, в вот гарантия расположения плеера по пути "/addappl/FPlay/fplay.kex" как раз будет гарантироваться схемой описанной в первом пункте это темы.

0CodErr wrote:Ядро ведь сейчас и так монтирует диски\флешки? А самому ядру для работы не нужно никаких программ.

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

0CodErr wrote:Этот поиск будет происходить один раз при старте или постоянно во время работы?
Ведь при переподключении диск отмонтируется и нужно будет снова его монтировать.

А как думаешь Linux Live CD работает? Если заставить систему отдать CD диск (а сделать это не просто, так как разработчики обычно отключаю такую возможность) - Linux тоже будет очень "удивлен" отсутствию диска. Загрузочное устройство нельзя вынимать до завершения текущего сеанса работы. И это вторая причина почему я не хочу брать все файлы тупо смонтировав на /sys - в случае если пользователь дурак и вынул таки диск, у системы еще останется рамдиск с самыми важными приложениями и данными.

CleverMouse wrote:Почему вместо UUID нельзя использовать текстовый файл с содержанием <номер версии>+<номер ревизии>+<язык>+<опциональный текст для пользователя "этот файл служит для идентификации раздела /addappl или как его там"? Кажется, это более понятно для конечного пользователя.

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

А если пользователь желает сам собрать свой дистрибутив - ему что теперь UUID генерировать руками?

А что мешает ? Так же как и lang.inc создавать.

Почему вместо UUID нельзя использовать текстовый файл с содержанием <номер версии>+<номер ревизии>+<язык>+<опциональный текст для пользователя "этот файл служит для идентификации раздела /addappl или как его там"? Кажется, это более понятно для конечного пользователя.

Кому как. Меня например парсинг строк ставит в тупик.
Идея была в том, что в корневом разделе диска создаётся каталог /KolibriOS и файл с совпадающим UUID именем подтверждает, что это именно тот каталог, который нужно смонтировать на /sys. В конце концов разделов с /KolibriOS может быть несколько, а поиск по имени файла раза в два быстрее поиска с последующим чтением. Это не мешает хранить в файле дополнительную информацию, например настоящий путь к программам KolibriOS.

Тогда так. В корневом каталоге хранится UUID файл, в котором записана вся информация необходимая ядру для монтирования /sys. Такой вариант позволит одновременно держать несколько разных дистрибутивов.
Таким способом можно делать многоязычные CD.