Board.KolibriOS.org

Mario
Как бы ничегонеделание для системы не отменяет логичности построений и высказываний...

SII wrote: Единственная ниша, где система может найти профессиональное, а не любительское применение -- это встраиваемые системы, однако там есть два "но". Во-первых, этот рынок не пуст, и в крупных проектах используются уже существующие ОС, которые не потеснить (QNX, OS-9, LynxOS, WinCE, клоны Linux, ещё несколько осей), поэтому можно претендовать только на всякую мелочь. Во-вторых, в большинстве встраиваемых систем используются процессоры, не принадлежащие к архитектуре ИА-32, причём из 32-разрядных безусловным лидером является архитектура ARM, а 16- и 8-разрядные архитектуры можно не рассматривать: первые вымирают в пользу ARMов и отчасти 8-разрядных, а 8-разрядные, как правило, работают вообще без ОС или с различными узкоспециализированными "микросистемами" (64-разрядные встраиваемые системы, по большому счёту, не встречаются за ненадобностью, хотя иногда применяются современные процессоры ИА-32). Однако разработка ОС не для ПК для большинства интереса не представляет, не говоря о том, что для этого нужно приобретать дополнительное оборудование (отладочную плату с ARM'ом, например), и в результате этим направлением занимается очень небольшое количество программистов (мне вот придётся этим заниматься по долгу службы, поскольку использовать кривой Linux никакого желания нет, коммерческие ОС маловероятны по финансовым причинам -- нольчайство удавится, если предложить такой вариант, а писать
программы для "голого" железа попросту тяжело, учитывая необходимость постепенно наращивать функционал, включая поддержку обмена данными по RS-232/485, CAN, USB и локалке; но я в данном случае выступаю не в роли системщика-любителя, а в роли профессионального наёмного программиста, и выбирать работу особо не приходится). В результате получается, что для основной массы потенциальных разработчиков ОС единственной приемлемой аппаратной платформой является ПК, а это означает, что о рыночных перспективах ОС лучше вообще не думать и определяться лишь с тем, чем она должна быть с технической, а не "экономической" точки зрения.

Ув. SII, мне очень сложно следить за стремительным полетом Ваших мыслей, особенно если он изложен столь неструктурированным образом.
В вышеприведенном абзаце, например, последнее утверждение логически совершенно никак не вытекает из первой части (с которой, конечно же, нельзя не согласиться).

Признавая наличие у Колибри (уже сейчас!) реальной ниши в секторе встраиваемых систем, Вы тем не менее рекомендуете нам перестать задумываться о ее внедрении и заняться ее полной архитектурной переделкой "как надо".

SII wrote: Пытаться латать существующие дыры и наращивать функционал позволит ещё некоторое время сохранять видимость жизнеспособности, но в конечном итоге всё равно всё закончится крахом: невозможно построить прочное здание без надлежащего фундамента.

Эти строительные метафоры, которые с легкой руки diamonda все подряд не устают повторять, меня уже порядком достали.
Лично мне КОС представляется не криво построенным домиком, а быстрорастущим живым организмом (тоже метафора, и вполне себе равнозначная). Если следовать этой ассоциации, то надо переходить с архитектурных споров на зоологические например:

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

SII из Зеленограда wrote: (кстати: ФТ-база!)

Зачем слушать того, кто ничего не может предложить?

diamond
Логика она такая логика (не лурк!), что можно шыворот на выворот все вывернуть и то что было сверху, станет снизу и наоборот. Вообще есть такая категория как http://ru.wikipedia.org/wiki/Демагогия

Mario, ты можешь сказать нечто конкретное в противовес сказанному или просто размахивать руками и говорить интеллигентным тоном "Пошли отсюда?"

ядерщики отписались, прикладнисты отписались, позвольте слово молвить пользователю (не смотрите на меня так, я реально пользуюсь Колибри, не из-за энтузиазма, а из-за достоинств оси, довольно-таки часто, и далее в посте расскажу как).
Во-первых это в какой-то мере будет ответ на вопрос ниши, во-вторых возможно поможет ядерщикам определиться с "новой веткой ядра", хотя напрямую пост относится не к этому. Он посвящен применению Колибри (возможно одному из тысячи возможных, а возможно и единственно возможному) в рамках не абстрактного, но совершенно определенного и конкретного пользователя.

Сегодня:
на данный момент в моем случае использование Колибри таково. В доме имеется более одного компьютера. Как вы понимаете, держать их все постоянно включенными - идея бредовая, поэтому постоянно работает только один. Но данные имеют привычку находиться не там где они нужны, верно? Так вот, если сразу к делу, то Колибри используется для просмотра фотографий на периферийном компе (смасибо Mario за отличный просмотрщик). К слову все фотографии там и хранятся. В этом же режиме работает проигрыватель дисков; это самое главное применение на данный момент.

Завтра:
или, проще говоря, чего я жду от Колибри. Идеальный сценарий использования: компьютер(ы) выключен(ы). Нужно что-то сделать (посмотреть фотки/посмотреть видео/поправить конфиги упавшей основной ОС/скопировать файлы/отправить имейл/погамать/программирование проекта(отдельный микродистрибутив под каждый проект)), флешка с Колибри вставляется в комп, комп включается. Загрузчик предлагает на выбор ряд микродистрибутивов (лежащих в папке в формате заархивированных .img, вроде это .imz), в которые и заранее собрал программы, нужные для конкретной цели. Если что-то нужное не поместилось в дистрибутив, кладу эти файлы просто на флешку, так как после загрузки она доступна не только по "железному" адресу, но и по (например) /ld/ (os was Loaded from this Disc), что позволяет прописать его в различные конфиги и в автораны микродистрибутива (например те же фотографии, если флешка объемная, могут храниться на ней же, соответственно можно сразу запускать фм или просмотрщик на папке с фотографиями, или в досбоксе путь до его игр). ОС загрузилась за считанные секунды, выполнила задачу, если надо, изменения дистрибутива записываются (одной кнопочкой, без ввода пути, или путь уже заполнен до файла с которого загрузилась система, а при желании можно исправить. а еще может быть в настройках микродистрибутива указано автосохранение рамдиска при выключении), компьютер выключается.

я не ядерщик, но по-моему и монолитное, и микроядро отвечают этим требованиям (они скорее к загрузчику), только в микроядре для микродистрибутивов можно еще и всякие системные вещи ненужные в данном микродистрибутиве выкидывать, так?

так вот, к чему это я. Эти требования означают следующее: системе нужна поддержка любого железа (хотя бы где файлы могут храниться) и файловых систем (чтение И запись ntfs, ext[2/3/4], запись дисков). Спящий режим при таком сценарии совершенно излишний, как и режим бездействия (компьютер проще выключить, ведь каждый микродистрибутив пользователь затачивает так, чтобы быстро продолжить работу (открываются нужные программы автораном и т.д.)) при загрузке системы. Возможность не использовать ненужные драйвера и вообще не включать в микродистрибутив - они бывают довольно объемными. Ну вот и все.. при быстрой загрузке у ОС в данной области не будет конкурентов (разве что реакт ось - линукс неповоротен на мой взгляд, я пробовал), не нужно обилие софта (только качество), ну вот вам и ниша. Лично я очень хотел бы видеть такую ось.

maximYCH
Все что нужно было мне лично я уже сказал, дальше будут только "лулзы" ибо тема усилиями всех превращается во флуд и оффтоп..

З.Ы. Не надо обижаться, на слова:

Впрочем ничего удивительного тему создал Максим

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

art_zh wrote:Ув. SII, мне очень сложно следить за стремительным полетом Ваших мыслей, особенно если он изложен столь неструктурированным образом.
В вышеприведенном абзаце, например, последнее утверждение логически совершенно никак не вытекает из первой части (с которой, конечно же, нельзя не согласиться).

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

Мои исходные утверждения:

1. Единственная ниша, где самописная ОС может найти практическое применение -- это встраиваемые системы, причём не любые, а достаточно простые, работающие не в слишком жёстких условиях и т.п. (для управления ядерным реактором никакой человек в здравом уме поделку непонятно кого не допустит).

2. Основная масса встраиваемых решений базируется на процессорах, не принадлежащих к архитектуре IA-32.

3. Для большинства системщиков-любителей единственной приемлемой платформой для разработки ОС является ПК, в основе которого лежит процессор архитектуры IA-32.

Вот из этих трёх утверждений и следует мой вывод: "о рыночных перспективах ОС лучше вообще не думать и определяться лишь с тем, чем она должна быть с технической, а не "экономической" точки зрения".

На всякий случай попробую объяснить, почему я прихожу к такому выводу. Обсуждаемую ОС разрабатывает коллектив любителей, для основной массы которых никакие аппаратные платформы, кроме ПК, практически незнакомы, не очень доступны и попросту неинтересны. Значит, эти разработчики готовы трудиться только над системой для ПК. Но, как известно, ПК во встраиваемых решениях почти не используется, там правят бал совсем другие архитектуры (из достаточно мощных -- прежде всего ARM). Следовательно, разработанная данным коллективом система не сможет найти применение в единственной нише, где есть реальные шансы на рыночный успех -- а значит, рассчитывать на таковой успех никаких оснований нет, и мысли о нём следует оставить, сосредоточившись лишь на технической стороне дела.

Признавая наличие у Колибри (уже сейчас!) реальной ниши в секторе встраиваемых систем, Вы тем не менее рекомендуете нам перестать задумываться о ее внедрении и заняться ее полной архитектурной переделкой "как надо".

Извините, но "уже сейчас" я у Колибри не признаю никакой ниши вообще. Я признаю лишь то, что любая любительская ОС, изготовленная на достаточно высоком уровне и для соответствующей аппаратной платформы, имеет неплохие шансы добиться рыночного успеха в секторе встраиваемых систем -- но КОС пока что этим требованиям не отвечает.

SII wrote: Пытаться латать существующие дыры и наращивать функционал позволит ещё некоторое время сохранять видимость жизнеспособности, но в конечном итоге всё равно всё закончится крахом: невозможно построить прочное здание без надлежащего фундамента.

Эти строительные метафоры, которые с легкой руки diamonda все подряд не устают повторять, меня уже порядком достали. Лично мне КОС представляется не криво построенным домиком, а быстрорастущим живым организмом (тоже метафора, и вполне себе равнозначная).

Ну, каждый вправе иметь свою точку зрения. Мне, если говорить о биологических метафорах, КОС, да и любой другой проект, создаваемый без нормального проекта, представляется эдаким мутантом из Чернобыля (точней, из страшилок о Чернобыле) -- с двумя головами, тремя хвостами и прочим, соединёнными друг с другом незнамо как, непонятно для чего и т.д. и т.п. Честное слово, говорю без всяких наездов, желания уязвить и прочая.

Кстати говоря, это Вы несколькими страницами раньше утверждали, что в существующих ОС невозможно реализовать нормальный семафор через общее поле памяти, доступ к которому осуществляется не программно, а аппаратно, самими внешними устройствами? Если Вы, то могу сообщить: в этом вопросе Вы абсолютно неправы, такой семафор без проблем создаётся в любой сколько-нибудь вменяемой ОС, причём без лишних плясок с бубнами. Если Вас это интересует, могу описать идею, как это можно реализовать (без привязки к конкретной ОС) на практике.

Пока тема совсем не утонула во флуде...
У меня есть черновой набросок микроядра для системы с единым пространством адресов. Зачатки SMP имеются. Он сделан для 32-х бит но относительна просто портируется на 64. Я выложу порт так что каждый желающий сможет допилить его по своему разумению. Микроядро превращается в монолит лёгким движением программистской мысли. Обратный процесс намного сложнее.

Что бы тема не утонула в флуде, нужно просто определиться, кому это интересно, а все остальные пусть продолжают копаться в текущем коде.

maximYCH wrote:Кроме того, я не знаю, насчет формата проектирования и обсуждения - подойдет ли для этих целей форум? Потому что, если да - куда это все запихнуть, если учесть, что микротемы теряются в ходе обсуждения? Выделять для каждой микротемы (Зачем, разрядность и т.д.) свою тему?

Технически, можно использовать багзиллу http://bugs.kolibrios.org либо trac http://new.kolibrios.org. Обсуждение и там возможно, а ещё есть зависимости между тикетами.

В long mode надо устанавливать правильный лимит tss или можно обойтись нулём ?

Also, unlike code-segment and data-segment descriptors, system-segment descriptor limits are checked by the processor in long mode. (c) второй том мануалов от AMD, раздел 2.2.3 Segmentation.

Да...
По теме делом занимается как я понял только Serge. Какие-то наработки есть у Марио и LRZ. Остальные занимаются теорией.
Тем кто это ещё не сделал советую ознакомиться с http://wiki.osdev.org/Projects и хорошо подумать. Хотите микроядро и POSIX - хорошо, только это уже будет не Колибри, вот моё мнение.

На форуме Колибри я понял некоторые важные правила:
1) Хочешь что-то сделать - сделай это сам! (c)Leency
2) Не обещать то, чего не сможешь сделать (а лучше всего, вообще ничего не обещать, а просто работать и сообщать про уже сделанные вещи). (c)Diamond
3) Уважительно относиться ко всем участникам форума, даже если порой некоторые люди часто пишут полную чушь на ваш взгляд, потому как в конечном итоге все мы объединены одним желанием - продвижение ОС Колибри.
4) Прежде чем отправить сообщение, убедись что оно не лишено смысла и может быть даже полезно.
...
Список можно продолжить.

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

Обещанная заготовка. В архиве приложен патченный bochs-2.4.2-smp.
Некоторая полезная информайия выводится в com1.

1. На ассемблер переписать можно, но знакомство с архитектурой AMD64 и просмотр кода в Боше отбивают всякое желание этим заниматься.
2. Я компилировал всё в Mingw64. Можно и в Linux но совместными усилиями Microsoft и AMD добились полной несовместимости ABI (в смысле соглашения о передаче параметров), а __attribute__((sysv_abi)) иногда ставит компилятор в тупик. Поэтому прежде чем вести дальнейшую разработку надо определиться с ABI и инструментами.
3. Менеджер памяти отсутствует.
4. Планировщик работает только на текущем процессоре (фактически это всегда bootstrap). Ap инициализируются, после чего бесконечно крутят idle_thread().
5. Адресное пространство 2Тб (значение взято с потолка), из них 512Гб ядро. Текущее адресное пространство описывается структурой as_t и доступно через this_as() (там ничего нет, только три страницы pml3 для user-mode).
6. Стек ring0 сделан в стиле Minix. На входе в ядро контекст сохраняется в структуре потока thr_t, после чего стек переключается на стек ядра. Для каждого процессора свои tss, стек ядра, очередь планировщика, и локальные данные процессора в cpu_t. Адресс структуры cpu_t хранится в [gs:0] и одновременно является вершиной стека ядра.
7. Ipc сделаны в стиле L4. Общий вид вызова int ipc(send_to, receive_from, timeout) где
send_to - поток-адресат сообщения
receive_from - поток-источник сообщения.
timeout - зарезервировано для разных RTOS извращений.
Варианты:
ipc_call(call_to) aka ipc(call_to,call_to)- посылает сообщение потоку call_to и ждет от него ответ.
replay(to) aka send(to) aka ipc(to, 0) - посылает сообщение потоку to
wait(from) aka ipc(0, from) ждёт сообщение от потока from, если from == -1, то от любого потока.
replay_and_wait(to) ака ipc(to, -1) посылает ответ потоку to после чего ждет сообщение от любого потока.