Я еще раз повторю свою мысль. Скорее всего я недостаточно определенно выразился в последних сообщениях. Мне кажется что система состоит не только из ядра, и если заняться только ядром, то через пару лет работы, все остальные части системы из-за неустоявщегося api провиснут до полностью неипользуемого состояния.
Я предлагаю сейчас отработать API. Если очень хочется адаптировать тот же Minix3 (4 тыс. строк.). А я считаю что лучше использовать микроядро.
После устаканивания API можно продолжить эксперименты и 32 и с 64.

Я готов портировать FreePascal под KolibriOS когда в ней появится нормальная система окон и система терминального вывода/ввода. Я готов поддерживать и в условиях (не готов а буду), но это будет сложнее сделать.

..bw

Mario79

Драйверу файловой системы не обязательно быть частью ядра. Он может компилироваться отдельным файлом и как бинарник включаться в ядро. После запуска ядро загрузит его из памяти. Так можно собирать вместе все необходимые для запуска системы компоненты. Многие системы так и делают.

bw
Minix интересная система, правда у неё есть особенности о которых Таненбаум скромно умалчивает сосредотачиваясь на вопросах надёжности и отказоустойчивости.
В Minix нет страничной памяти.
Изолированность адресных пространств достигается при помощи LDT. Каждый процесс получает свою локальную дескрипторную таблицу с дескрипторами кода и данных. Так что существующее микроядро можно считать идеальной реализацией сегментной организации памяти которая уже и не применяется. Вероятно по этой причене нет версии для AMD-64 где страничная память является единственным механизмом защиты.
Относительная небольшая потеря производительности в 8-12% при переходе на микроархитектуру объясняется именно этим. Реализация межпроцессных вызовов и необходимость копированиия данных между разными адресными пространствами а не разными сегментами увеличит объём кода и снизит скорость вызовов. Таненбаум обещает представить систему с виртуальной памятью. Интересно что из этого получится.
Пока же организация памяти в Minix очень похожа на устройство памяти в МеОС

Я не буду с тобой спорить, так как я вляюсь прикладником и на системном уровне разбираюсь очень плохо. Хотя и профессионального предмета то для спора нет.
Мне кажется что команда KOS не в состоянии сделать конкурентно способное ядро, да это и не нужно. А стабильность нужна. Под микроядном, например, я мог бы отлаживать драйвер для своей карты видео захвата, не боясь что система рухнет, и не пересобирая ядро. Для себя в данном проекте я вижу много др. прикладных задач на системном уровне . Я являюсь негласным руководителем проекта freedune, замороженного до лучших времен. Он будет продолжен либо на Python (без совместимости с KOS), либо Pascal (и возможно Си). но мне хотелось бы работать с взрослой ОСью, и не иметь дело с подростковыми прыщами.
Для себя я вообще хочу получить систему которая стартует в минимапльное время, т.е. не приходится ждать несколько минут для её полной загрузки (это из пожеланий, основных).

..bw

bw

Мне тоже нравится идея вынести драйвер в user-mode. Но на это нужно время.

Serge

Мне тоже нравится идея вынести драйвер в user-mode. Но на это нужно время.

А мне не нравиться идея. Вот к примеру стоит у меня навороченный драйвер видео карты с поддержкой opengl на аппаратном уровне а температуру видео карты не показывает. Исподников нет. Но я знаю как узнать температура но для этого мне нужен доступ к регистрам видео карты. Которые находиться в монопольном доступе у того навороченного драйвера. Что мне делать?
На ум приходит только инжект в процесс драйвера. По мне как то не очень. А так пока драйвера рядом с ядром я спокойно могу написать свой.

Pavia

В Колибри нет монопольного доступа. При желании его всегда можно получить.

Pavia
Темературы (а также напруги, вентили, PLL, тайминги памяти и DDC) на видяхах доступны через SMBus (бывает до 3-4 шин на карточку), естественно что для каждого вендора свои порты, но они не пересекаются с остальным функционалом. И ты спокойно можеш их использывать.
P.S. Если кто нибудь разработает под Колибри OpenGL драйвер для моей видяхи то мне будет "всё равно" до температуры )
P.S.S. Вынесение дров IMHO ускорит написание оных, т.к. не нужно будет тратить время на ковыряние ядра с вопросами "как это работает" и "куда бы это прикрутить".

Дрова в user-mode можно гонять под отладчиком. В режиме ядра с этим всегда проблемы. Я сэкономил бы кучу времени если бы мог протрассировать вызов драйвера в mtdbg

Во пошла жара!
Попробую высказаться по поводу:

Pavia wrote:To Serge
Помойму этому проекту, нехватает цели. А вернее плана. Как только появиться план станет ясно что нужно сделать. Как только станет ясно что сделать в процессе разработки выявяться недостатки. И уже тогда точно будет понятно, что нужно делать.

Pavia тут все несколько не так. Я вижу, что ни четкой цели, ни плана нет и не было, а вот недостатки были и есть. Но выдвигать цели и планы, как продолжение известных НЕоправданных направлений развития врядли стоит.

Mario79 wrote: При нашем дружном сообществе, где человек человеку: "Товарищ волк знает, кого кушать..." - мы далеко не уедем к сожалению.

Можно с тобой согласиться и поверить, что это так. Тогда есть еще один весьма важный вопрос любого серьёзного проекта - его ОРГАНИЗАЦИОННые принципы, ПРАВИЛА взаимодействия участников и я бы даже сказал ПРАВА и ВЕС голоса. От этого будет зависеть МНОГОЕ. Иначе прибежал некто, зазвал, соблазнил амбициозно, без аргументов многих и одним махом некая часть разработчиков очень даже демократично и безответственно принялась тестировать приложения-игрушки, похеряв тем самым, скажем отладку и тестирования нового ядра или ... драйверов.

Serge wrote:Pavia и все
Хорошо. Вот план.
1. Программное переключение задач
2. Новая система система сообщений
3. Планировщик
4. Диспетчер устройств
5. Загружаемые драйверы и модули в форматах PE и ELF
.............

Стоп! Стоп! Это сгоряча или как? Ну давай хотя бы немного (без этого нельзя, раз есть такой нарыв и он СОЗРЕЛ!) будем кивать на ту ветку форума и вспоминать про то, что (С) на ядро и чуть ли не воровским продуктом называют эти самые виллисы и его "стая"...
Уже первые пункты говорят, про то, что НУЖЕН РАДИКАЛЬНЫЙ ПЕРЕСМОТР ядра, раз такие пункты!
А раз так, я например, в данном конкретном случае, расцениваю участие в работах по данному перечню - КАК НОВЫЙ ПРОЕКТ(!) ибо это НОВОЕ ЯДРО(!), новые принципы, механизмы, код... Иначе я не согласен!
ЭТО (и перечень и принцип, подход) для меня лично было года три назад основным и послужило к разрыву с менуетом тогда и началу радикально нового проекта, несмотря на все многочисленные трудности и ОТСУТСТВИЕ хоть какой либо массовой поддержки и взглядов и дела...
Нафига менять БОЛЕЕ 50% ЯДРА (равно как его принципов работы, распределения...) и признать (С) и права на собственность, типа, и голоса... для вилли!??? Опять доказывать ему, что это не его меОС? Ради чего? Ностальгия?
Клятвы верности виллису, его ядру, верность менуету т.к. это приятные воспоминания?

bw wrote:Что касает ядра и планов. Идея создания ядра своими силами не внушает в меня оптимизма. Создание и отладка ядра может затянуться на несколько лет. А все баги промежуточных версий не позволят нормально развиваться прикладному ПО и драйверам системы.

Не согласен! Все настолько и созрело и даже перезрело(сама идея нового ядра), за последние 2-3 год, что ты бы сам очень удивился и вдохновился, НО! Но у нас у всех, кто юзал, писал, модифицировал, для менуетОС ядра и его производных НЕ было и НЕТ главного - единения усилий, планов, солидарности, уверенности...
Многие, я не боюсь этого слова ТАЛАНТЛИВЫЕ ребята, да и чего скрывать, даже опытные мужи увлекались, пробовали, советовали, консультировали, писали... для ЭТОГО проекта. Но далее, как правило, без прощальных речей а это весьма печально и важно(!) без ОГЛАШЕНИЯ почему и из-за чего они ПОКИДАЛИ ПРОЕКТ, его поддержку, интерес к нему и т.п.
Если поднять глубоко историю, то так, через менует прошли несколько волн, бригад, групп и отдельных замечательных личностей, которые, Я УБЕЖДЕН! Запросто и давно бы перекроили все ядро и я даже знаю, что это было и у кого, но вилли...
Чего греха скрывать, я вот смотрю годик за работой Serge и вспоминая некоторых ушедших, постоянно задаю себе немой вопрос, на сколько его ТУТ хватит? А быть может этот парень не повторит "своих предшественников"? Может потянет и НЕ надорвется то сам? А ведь жалко парня, блин, может сказать надо, что так уже "ходили", может пообщаться...?

Mario79 wrote:Я против использования компиляторов высокого уровня для ядра

Конкретно по ЯДРУ - полностью поддерживаю! Остальное обсуждаемо у ходе эволюции работ, смысла, трудозатрат, эффекта и эффективности т.п.

G@K wrote: З.Ы. Пытаюсь навоять драйвер USB

Молодца! Если на АСМе и это FASM и уже есть наработки (скажем под DOSом) и нужно участие, помощь, тестинг... могу попробовать перепланировать свои планы и присоединиться к совместной работе для доведения до звания полноценного драйвера

Sniper wrote:Да в продолжении темы про маленькую ОС. На асме не написать такие вещи как Firefox, Thunderbird, OOo их придётся портировать. Но на асме можно написать небольшие программы типа видео просмотрщика, аудио плеера, смотрелку картинок, программу записи дисков...

Ребята, давайте разделять разумное от неразумного, неоправданного, неоптимального. Мы в основном ведь говорим об ассемблерной ОС, так? Так. Так вот СЕРДЦЕ ОС, а именно ядро, ну пусть и менеджеры, сервисы и по возможности ОСНОВНЫЕ дайвера нужно делать на НЕМ! ЯДРО - 100% Иначе проект НЕ ИМЕЕТ права, на мой взгляд, называться ассемблерным! Моё мнение.

Serge wrote:Драйверу файловой системы не обязательно быть частью ядра. Он может компилироваться отдельным файлом и как бинарник включаться в ядро. После запуска ядро загрузит его из памяти. Так можно собирать вместе все необходимые для запуска системы компоненты. Многие системы так и делают.

100% да! Я в этом ключе и проектировал ранее своё детище...

ВСЕМ.
Мужики, давайте, быть может, не каждый о своем, а о общем говорить.
Нафига СЕЙЧАС говорить о драйверах, языках их создания, уровнях привилегий...???
ВЕДЬ ВСЕ ЭТО ПЛЯШЕТ ОТ ЯДРА! ЕГО РАБОТЫ и СТРАТЕГИИ!!!
Для меня два важных вопроса НА СЕГОДНЯ ядро продолжает быть убогим и принципиально старым по существу или
это совершенно новое ядро с вытесняющей многозадаяностью, планировщиком, расфасовкой RING(0-3) по полочкам и это оправдано, т.к....
И это соответсвенно новый проект(убежден, что новым творческим и знающим людям заинтересовавшимся ассемблерной осью, реалиями и фактами) все равно и ностальгия по менуету или колибри им не грозит, им важно дело, результат, убеждение правильности приложения своих усилий, времени, знаний именно в НОВЫЙ ПЕРСПЕКТИВНЫЙ проект = новое имя, т.к. они разделяют и согласны с его основополагающими вещами.

Да, вот еще, что. По поводу 32 и 64 битности, скажу, что предрассудки думать, что драйвера для именно 64битной системы должны быть какоието особенные 64битные, крутые, более производительные и т.п.
Кто хоть раз программировал для железа, особенно современного, знает, что приходится оперировать и 8ми и 16ти и 32битными обращениями к портам! Ну скажите на милость, как изменится часть кода считывающего символы с Ваше клавиатуры если он (архитектура РС обязывает!) всегда начинался как: что скан коды изменятся или уникальный байт ИНФОРМАЦИИ в AL будет преобразован ЗАТЕМ в 64битное значение и далее использовано в драйвере именно так? Чушь и НЕ показатель и НЕ характерно и тем более НЕ АРГУМЕНТ в пользу того, что 64битная ОС НЕ может использовать "старый" код или он очень НЕпроизводителен теперь (а ведь будет тот же IN AL, 0x60 в x64 архитектура однако, совместимость!)... почемуто(?).
Теперь по поводу всеобщих уходов от ОСНОВНОГО в модификациях, за и нет и почему. Предлагаю ПРЕКРАТИТЬ описание СВОИХ хотелок и приведение перечней(особенно неаргументированного мечтательного характера), это лишь ВРЕДИТ, особенно в плане ознакомления с осью, участниками их трезвомыслием, если хотите.
А вот ПРИВЕТСТВОВАТ НУЖНО и необходимо кристаллизацию НЕОБХОДИМОГО МИНИМУМА БЕЗ КОТОРОГО ДАЛЬШЕ НЕЛЬЗЯ!
Который нельзя игнорировать, нельзя НЕ видеть ибо это проблема влекущая за собой (и это надо сказать, говорить, чтобы понял каждый). Т.е. я бы с удовольствием тут видел именно - это отсечение шелухи второстепенности и т.д., а наличие приоритеного перечня пусть малых, но очень серьёзных изменений ИХ НЕОБХОДИМОСТИ.
Например, читаю следующее.
Обоснование нового переключателя задач и супервизор системы на основе таймерных IRQ0 + IRQ8, таймерный мониторинг задач и механизм вытеснения внутри приоритетных групп.
Квант времени не более 1мкс. Как он достигается, почему необходим.(описание) и т.п. по "сердцу ОС" и как ему жить.

VaStaNi
Все конечно верно, но мы так и не определились:
1) Структура ос: монолит или микро.
2) Механизм подключения драйверов (абсолютно разный для вариантов п.1, и даже в самих вариантах могут быть подварианты)
Есть еще много чего, но ИМХО не решив этого, дальше не поедет вообще ничего...

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

Mario79 wrote:VaStaNi
Все конечно верно, но мы так и не определились:
1) Структура ос: монолит или микро.
2) Механизм подключения драйверов (абсолютно разный для вариантов п.1, и даже в самих вариантах могут быть подварианты)
Есть еще много чего, но ИМХО не решив этого, дальше не поедет вообще ничего...

Да вроде и не начинали еще определяться. Пока ходим я так понимаю вокруг ДА и НЕТ, мыслим кто как может или "видит"... Общие понятия чтоли. Если конктретно по п.1, что я думаю, то у меня(у нас) в свое время было решение о комбинированном строении, а не идти шаблонно, штампованно. Т.е. и не микро и не монолит, а комби!
Поясняю. Если взвесить "+" и "-" одного и другого, то получится, что выгодно иметь микроядро с псевдомонолитным вкраплением драйверов де-факто, например, менеджеров... Псевдомонолит - по сути монолит, но "подключение" в ядро осушествляется... ну проше сказать и грубо, скажем, как REP MOVSD в фиксированный адрес ядра, тем самым после "самосборки" начального (базового, фундаментального) ядра оно в памяти выглядит и работает (межблочно), как монолит (т.е. тут все плюсы именно его). Драйверы же, особенно сторонние... ну пусть пофантазируем ATI грфич.ускоритель, например грузятся именно, как драйверы в решении микроядра, соотв. подключаются и работают, через соотв. механизмы. Естественно мудрёно получается, но оптимально. Даже если учесть то, что можно плавно вытеснять, потихоньку нечто монолитное в загружаемое/выгружаемое или вообще пользовательское решение да или нет. Следующий пример. В ядре есть некий убогий, ограниченный GUI, но худо бедно он работает (VESA) или только он работает у юзера, т.к. конкретного драйвера под железо нет. Аоявился драйвер. Юзер может попробовать его без перекомпиляции ядра, задав в неком CFG загружать этот драйвер. Непошел он - возврат к старому без переделки... И т.д.
Ну тут собственно немного и по п.2 прошелся. Думаю прояснил то, что имею по этому сказать. Хотя это кратко.

<Lrz> wrote:VaStaNi
Я так понял, что ты будешь участвовать в проекте, только если будет четкий план действий, согласованность людей, участвуеющих в разработке, и проект должен быть с новым названием.
Мне все понятно, чем тебе название не угодило ? Лично мне название нравиться и отражает суть, быстрая, эффективная...
Или название стоит сменить, только из-за того, что сейчас код КООС базируется частично на коде Menuet ? Если будет разработано новое ядро, без когда "товарища" Вилле, он не сможет оспаривать авторские права, т.к. будет уже совершенно другая логика и другой код. Или ты думаешь, он будет по старой памяти это делать ?

Частично отвечал в теме по копилефты, повторять не буду. Далее. вилле - ни Я ни многие другие, с коими беседовал не раз, НЕ ВЕРИЛИ и НЕ БУДЕМ ВЕРИТЬ, "верилка" кончилась, "терпелка" и того давнее...
Посему бегать по всему свету (по всем форумам, которые знаю или не знаю, публикациям) и опровергать, что дескать этот, скажем KOS проект и название не имеют ничего общего с таким же в написании KOS проектом..., вот тут и тут не так и не надо бумать, почитайте, ознакомтесь, не путайте, дескать уважаемые то и это..... Поверят? Кто поверит, сколько их будет, зачем утруждаться...
Проще отрубил, так отрубил, как гангрену. Вполне допускаю, что мой подход слишком категоричен, но я не бьюсь головой дважды об одни и те же двери(во всяком случае стараюсь) + учусь на чужих ошибках, например, менует реалии и иже сним.
Я не зря иногда про пуповину гутарю. Её ведь отрезают и залечивают, а ведь так спокойно то, вообщем, с пуповиной жить, можно даже не жевать... Где то так получается у меня.