NOKIA Booklet 3G + Kolibri OS

Using Kolibri in embedded systems
  • Fanatic wrote:но я вот так вот не могу разбираться и работать, когда всё через какие-то "выверты"...
    Почему вы считаете рамдиск "вывертом"?
    Fanatic wrote:Пусть лезет.
    Для приложений, запускаемых ядром, этого не будет. Другие приложения можете запускать откуда угодно. При желании можете в autorun.dat, menu.dat, icon.ini прописать пути на винте - тогда launcher, @menu и @icon соответственно будут дёргать винт.
    Fanatic wrote:мне вот 4 человека пытались объяснить: что и как работает - ничерта не понятно, сплошные "рецепты" для безруких, а не теор часть.
    Вы спрашиваете "как мне это сделать" - вам пытаются объяснить, как это сделать. Хотите знать, что внутри, - так и спрашивайте. install.txt - это инструкции, что делать, а не как оно работает. Вас интересует что-то конкретное?
    Сделаем мир лучше!
  • Fanatic wrote:Опыт разработки технической документации имеется (4+ года).
    По стилю речи понятно, что есть опыт разработки технической документации. ;) Правда иногда такую речь труднее воспринимать даже, чем вольное изложение, несмотря на кристальность терминологии и попытку объять все возможные варианты. Пример - различные государственные законы (по крайней мере в РБ). Порой кажется, что для этого нужен какой-то особый склад ума.
  • CleverMouse wrote:
    Fanatic wrote:Пусть лезет.
    Для приложений, запускаемых ядром, этого не будет.
    По какой причине?
    Почему ядро неспособно обращаться ко всем требуемым для его работы файлам, если они расположены непосредственно на носителе, рядом с ним?
    Над чем конкретно и какие именно потребуются усилия чтобы реализовать требуемое?
    И последнее: известно, что такая возможность была раньше. Почему сейчас вопрос с обсуждаемым обстоит как "невозможно", вместо "теоретически возможно, но работа не гарантируется"?

    Исходя из теории, загрузчик должен передавать управление ядру ОС, которое, в свою очередь, загружает всё что ему требуется в память ОЗУ. Я не против, чтобы ОС помещала свои данные в ОЗУ - собственно, я и не могу быть против этого, так ОС работает - я против того, чтобы она БРАЛА данные из образа.
    Хорошей иллюстрацией служит пример с игровым ПО, где запускаемое приложение может брать нужные ему данные из образа в PAK-файле, а может непосредственно загужать данные из файлов, расположенных в заданных местах. Последнее удобно, когда происходит отладка "дополнений" и делается живая замена файлов прямо на диске, без необходимости каждый раз собирать PAK-образ.
  • Fanatic wrote:По какой причине?
    Главным образом, по идеологической.
    Fanatic wrote:Почему ядро неспособно обращаться ко всем требуемым для его работы файлам, если они расположены непосредственно на носителе, рядом с ним?
    Потому что для работы с носителем нужен ещё и драйвер носителя. Драйвер IDE встроен в ядро только по историческим соображениям. Как и файловые системы, впрочем. Драйвера USB-флешек и SATA - отдельные файлы, которые надо прочитать до того, как будет возможна полноценная работа.
    Fanatic wrote:И последнее: известно, что такая возможность была раньше. Почему сейчас вопрос с обсуждаемым обстоит как "невозможно", вместо "теоретически возможно, но работа не гарантируется"?
    Она и раньше скорее не работала, чем работала. Минус полтора метра памяти под неиспользуемый рамдиск, жёсткая привязка к координатам на IDE, необходимость наличия DOS. И главное - отсутствие поддержки при изменениях ядра, которых с того момента было много.
    Fanatic wrote:Исходя из теории, загрузчик должен передавать управление ядру ОС, которое, в свою очередь, загружает всё что ему требуется в память ОЗУ.
    У вас неточные представления о теории. Загрузчик должен загрузить не только ядро ОС, но и данные, необходимые для инициализации. В Linux точно так же грузится образ рамдиска, только там он read-only и, соответственно, не FAT, а что-то вроде squashfs. В Windows загрузчик читает реестр и загружает драйверы, указанные в нём.
    Fanatic wrote:Над чем конкретно и какие именно потребуются усилия чтобы реализовать требуемое?
    Есть вариант заставить загрузчик создавать FAT-образ динамически при загрузке по отдельным файлам, чтобы с точки зрения ядра оставался /rd/1, но kolibri.img был бы виртуальной сущностью, не присутствующей в виде отдельного файла. Для не слишком толкового, но и не совсем бестолкового, разработчика - ориентировочно месяц разработки.
    Сделаем мир лучше!
  • CleverMouse wrote:
    Fanatic wrote:Почему ядро неспособно обращаться ко всем требуемым для его работы файлам, если они расположены непосредственно на носителе, рядом с ним?
    Потому что для работы с носителем нужен ещё и драйвер носителя. Драйвер IDE встроен в ядро только по историческим соображениям. Как и файловые системы, впрочем. Драйвера USB-флешек и SATA - отдельные файлы, которые надо прочитать до того, как будет возможна полноценная работа.
    Вот где всё дело, докопался! :) Большое спасибо.
    Теперь всё становится на свои места: даже если встроить поддержку SATA и USB на уровне ядра, то в случае потребности в малейших изменениях драйвера или банального апдейта поддержки устройств - каждый раз потребуется правка ядра, что явно не целесообразно.

    Но, к сожалению, как раз именно этот вариант - и есть искомый :))))))))))))
    Боюсь даже спрашивать, сколько потребовалось бы человекочасов на встраивание USB- или SATA-драйвера на уровне ядра, хотя бы в том виде, в котором драйвера сейчас есть...

    CleverMouse wrote:
    Fanatic wrote:Над чем конкретно и какие именно потребуются усилия чтобы реализовать требуемое?
    Есть вариант заставить загрузчик создавать FAT-образ динамически при загрузке по отдельным файлам, чтобы с точки зрения ядра оставался /rd/1, но kolibri.img был бы виртуальной сущностью, не присутствующей в виде отдельного файла. Для не слишком толкового, но и не совсем бестолкового, разработчика - ориентировочно месяц разработки.
    Теоретически способ вполне работающий.
    Насколько я понимаю: виртуальный образ собирался бы при каждой загрузке из того, что находится на носителе. С изменением содержимого на носителе - содержимое собираемого при загрузке виртуального образа изменяется.
    А как загрузчик увидит файлы на носителе?..
  • Fanatic wrote:А как загрузчик увидит файлы на носителе?..
    Так же, как он сейчас видит файл kolibri.img.
    Сделаем мир лучше!
  • Heavyiron wrote:
    Fanatic wrote:Опыт разработки технической документации имеется (4+ года).
    По стилю речи понятно, что есть опыт разработки технической документации. ;) Правда иногда такую речь труднее воспринимать даже, чем вольное изложение, несмотря на кристальность терминологии и попытку объять все возможные варианты. Пример - различные государственные законы (по крайней мере в РБ). Порой кажется, что для этого нужен какой-то особый склад ума.
    Иногда бывает и так :)
    Как мы знаем, капиталистическому миру присуща анархия производства и отсутствие взаимоувязанной целостности во всём, поэтому любые стандарты изменяются так часто и настолько быстро, что конкретные инструкции столь же быстро устаревают. И инструкции приходится столь же часто обновлять.
    В условиях свободной разработки это превращается в адскую мешанину: кто-то каждый раз вносит правки ссылаясь на что-то, второй дополняет и не учитывает ссылки, третий вносит ещё одни дополнения в уже третьи материалы и со временем этот ворох разобщённых инструкций разрастается до таких масштабов, что разобраться в них становится огромной анальной болью и нервотрёпкой: пытаешься собрать мозаику воедино, но у тебя ничего не получается кроме разрозненных огрызков, из которых ни черта не ясно. На вики одно, там другое, в доках третье, на сайтах четвёртое, на форуме - пятое...

    Я считаю, чтобы это побороть нужно максимально донести саму идею того, как ведёт себя ОС и что ей нужно. Человек сможет сам собрать себе систему в соответствии со своими потребностями и сам выбрать метод.
  • CleverMouse wrote:
    Fanatic wrote:А как загрузчик увидит файлы на носителе?..
    Так же, как он сейчас видит файл kolibri.img.
    Понял, стормозил.
    Что ж, это был бы отличный вариант.
  • Fanatic wrote:Я считаю, чтобы это побороть нужно максимально донести саму идею того, как ведёт себя ОС и что ей нужно. Человек сможет сам собрать себе систему в соответствии со своими потребностями и сам выбрать метод.
    Если сюда заглянет Leency, он расскажет, что пользователю нужно только знать, какие кнопочки нажимать, и ни в коем случае не смотреть внутрь. В идеале инструкция должна содержать три строчки, которые один раз сработали у Leency, и ни в коем случае не грузить пользователя вариантами.
    Сделаем мир лучше!
  • Well, никто не мешает иметь короткий мануал для тех, кто хочет результат, и длинный для тех, кому важны детали.
  • Конечно же, если какие-то строчки сработали на компьютере Leency, это автоматически даст результат на любом компьютере с любым железом под любой операционной системой, поэтому все остальные строчки можно выкинуть или задвинуть куда-нибудь подальше.
    Сделаем мир лучше!
  • Leency довел до крайности, ты уводишь в другую крайность. Запутанные непонятные мануалы - это плохо.
  • SoUrcerer wrote:По поводу сохранения - вы, вероятно, стали жертвой SaveDialog. Чтобы сохранить файл, недостаточно выбрать папку. Нужно щелкнуть по полю ввода имени файла, и лишь затем нажать Save. Попробуйте.
    Вообще то если быть более точным в выражениях и логически последовательным, то фокус выборы должен либо стоять в поле ввода имени, либо в области списка файлов и будет располагаться на файле. Если же он на директории или на "..", то кнопка "Save" меняет текст на "Open" и тогда действительно нужно переключать фокус на область ввода имени файла.

    З.Ы. Если кто то более умный и способный сделает OpenDialog лучше - я сам лично своими руками выпилю текущий OpenDialog из дистрибутва и SVN. Поскольку выслушивать каждый раз голословные обвинения мне надоело. А пока нет альтернативы все будут "вкушать" то, что я приготовил. На этом обсуждение OpenDialog в этой теме считаю законченным.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Флуд, удалено.
    Last edited by Fanatic on Tue Nov 19, 2013 4:59 pm, edited 1 time in total.
  • Who is online

    Users browsing this forum: No registered users and 5 guests