Новая ветка ядра
-
ладно, каждый думает, как хочет (мы можем долго спорить, но от основной темы мы и так отвлеклись). Но, что я знаю точно и проверил на собственной шкуре: НИКТО не будет делать ничего в сторону встроенных решений кроме Вас, если САМ того не захочет. В сообщении #33, Вы высказали свою позицию, и я должен Вас разочаровать: на собственной шкуре понял, что в этом проекте каждый сам по себе. И заставлять людей (эксплуатировать) просто не возможно, у Вас это не получится. Ну а то, что Вы высказали свою позицию - отлично. Поэтому собственно я до сих пор не вижу проблем с embedded.
Общее число строк во всех файлах *.asm и *.inc в kernel/trunk на момент ревизии 1380 составляет 71100. (Кстати, к вопросу о связи с Menuet: от первой ревизии aka "Kolibri 5 initial checkout" осталось всего 6976 строк = 9.8%. Впрочем, первая ревизия всё ещё остаётся лидером по количеству строк кода, доживших до текущей ревизии, обгоняя 261-ю "John's ethernet stack updates && NEW subfunction 52-17" с 5718 строчками и 1065-ю "add Secondary Loader".)maximYCH wrote:Сейчас в ядре ~30 000 кода.
Любой код будет глючить в той или иной степени, и нет оснований считать, что старый код будет глючить больше просто потому, что он старый. Собственно, есть подозрение, что, наоборот, новый код будет глючить сильнее просто в силу того, что из текущего кода глюки старательно выбиваются уже несколько летmaximYCH wrote:Казалось бы, ядро тогда будет в порядке, т.к. основное переписали. НЕ БУДЕТ. Старый код будет глючить в связке с новым, и будет куча проблем.
Как это ни странно, на уровне хобби развитие вполне себе идёт, хоть и мало ресурсов. И даже дошло до указанных выше ~70000 строк (оно, конечно, понятно, что не в строчках кода счастье, но как один из показателей годится). Так что и без коммерческого развития дела будут идти и дальше.Mario wrote:На уровне хобби проекта развитие очень медленное, так как мало ресурсов. Как коммерческая система тоже не тянет - нет спроса. Можно конечно сто раз написать как все можно сделать замечательно и почему до этого это все не было сделано, но по сути ничего не меняется. Эффект Linux нам не повторить. По этой причине я лично вижу только путь коммерческого развития. Давайте честно признаемся сами себе - что выделять даже 30 минут в сутки в среднем получается пока есть энтузиазм, а он как показывает практика достаточно быстро заканчивается.
Архитектура x86-64 вполне себе совместима с x86. Текущая 32-битная Колибри вполне себе работает на 64-битных процессорах, хотя и не используя 64-битность как таковую. Пример Menuet64 показывает, что можно относительно малыми силами сделать и 64-битность, оставаясь в рамках ассемблера. Так что заявления, что "придётся всё заново переделывать", представляют из себя слишком сильное преувеличение.andrew_programmer wrote:Я тоже об этом думал. Микроядро на чистом ассемблере. А "обвес" хочешь на C, не любишь C, так ассемблер. Это единственный способ снизить зависимость от: x86-32/SMP, x86-64/SMP. А иначе возьмут Intel и AMD, и придумают какую нибудь Asymmetric Multi Processors с кучей ядер, и придётся всё заново переделывать.
AT&T синтаксис ассемблера не имеет к Си как таковому ни малейшего отношения.andrew_programmer wrote:Некоторых от C, а уж тем более от AT&T синтаксиса встроенного ассемблера вообще выворачивает наизнанку.
Угу. Пока что ковыряние привело к, по крайней мере, работающей системе.Mario wrote:Хорошо будем ковыряться дальше в песочнице.
Ушёл к умным, знающим и культурным людям.
Ну, вот на форуме появился Главный и расставил все точки над Ы...
А иногда - странно, правда? - люди берут и делают то, за что им ни добрые дяди не платят деньгами/привилегиями, ни злые дяди не угрожают расправой. Вот, например, мы все сидим на этом форуме, некоторые из нас даже пишут код для Колибри, причём случаев пистолета у затылка, равно как и зарплаты за продвижение Колибри, замечено не было.Mario wrote:От людей можно что-либо требовать лишь поставив их в зависимость - например ЗП, наличие определенных привилегий, можно еще к затылку приставить пистолет, т.е. угрозой расправы, других способов человечество не придумало.
Вообще есть разумные требования, которые разумные люди могут выполнять и без дополнительных ограничений/поощрений.
Во-первых, я тут не Главный или, точнее, не единственный Главный, ещё Serge есть Во-вторых, я только в процессе чтения этойMario wrote:Ну, вот на форуме появился Главный и расставил все точки над Ы...
Ушёл к умным, знающим и культурным людям.
Имелось ввиду, что связка старого кода и нового кода породит проблемы соответствия и совместимости, отладки и т.д.Любой код будет глючить в той или иной степени, и нет оснований считать, что старый код будет глючить больше просто потому, что он старый. Собственно, есть подозрение, что, наоборот, новый код будет глючить сильнее просто в силу того, что из текущего кода глюки старательно выбиваются уже несколько лет
Ты игнорируешь то, что в 32битном режиме можно адресовать только 4 Гб, а сейчас как раз по 4Гб и ставят, как следствие, будут ставить ещё больше. И юзеру ОС уже выйдет не бесплатно, т.к. ОС не позволяет использовать купленные ресурсы. И вообще, ничего, что простая замена eax-rax и т.д. не есть суть архитектуры? Это ПОЛНОСТЬЮ новая архитектура во многих местах, и игнорировать возможности (учитывая, что это по факту промышленный стандарт) - отказ от будущего.Архитектура x86-64 вполне себе совместима с x86. Текущая 32-битная Колибри вполне себе работает на 64-битных процессорах, хотя и не используя 64-битность как таковую. Пример Menuet64 показывает, что можно относительно малыми силами сделать и 64-битность, оставаясь в рамках ассемблера. Так что заявления, что "придётся всё заново переделывать", представляют из себя слишком сильное преувеличение.
Я тебя не понимаю. То ты пишешь, как все криво, то как все хорошо. Определись, пожалуйста. Ты описывал слабость графического интерфейса. Сейчас есть разработчики, готовые переделать его. Но при этом часть графики плотно зашита в ядро. Впихивание всего в ядро - это плохо, и это не мои слова - это слова многих других разработчиков этого сообщества. То же самое с PnP. Можно немного пояснить логику своих ответов на форуме по этим вопросам?Угу. Пока что ковыряние привело к, по крайней мере, работающей системе.
То что совмести - это спасибо AMD. А вот насчёт адаптации под 64 бита 70 тысяч строк кода не всё так тривиально... Отсутствие режима virtual86, добавление 8 новых 64 битных регистров общего назначения, и 8 новых xmm8-xmm15 регистров, изменяется размер и адреса переменных в памяти. Вместо mov eax,[ecx*8+4] будет mov rax,[rcx*16+8]. И возникает вопрос, как совмещать 32-х и 64-х битный код? Писать 2 версии алгоритмов, увеличивая в 2 раза объём работы? А если ещё SMP учесть.... Лично мне нужна максимальна производительность от всех ядер процессора и всех регистров. Численное моделирование этого требует.Архитектура x86-64 вполне себе совместима с x86. Текущая 32-битная Колибри вполне себе работает на 64-битных процессорах, хотя и не используя 64-битность как таковую. Пример Menuet64 показывает, что можно относительно малыми силами сделать и 64-битность, оставаясь в рамках ассемблера. Так что заявления, что "придётся всё заново переделывать", представляют из себя слишком сильное преувеличение.
Ключевое слово встроенного ассемблера. Ибо добавляется %0,%1...,а также "r=","m","r","g",.... куча всяких особенностей чем должен заменить компилятор gcc соответствующий символ(регистр, переменная, константа и т.д.).AT&T синтаксис ассемблера не имеет к Си как таковому ни малейшего отношения.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Моя позиция по поводу предназначения - десктопы. Обоснование: на "серьёзные" объекты неизвестную ОСь просто не пустят, так что перспективы в отношении серверов, равно как и встраиваемых систем, исключительно туманны. На собственный десктоп, по крайней мере, поставить "на посмотреть" может практически кто угодно из продвинутых ITшников, что даёт какую-то известность и какой-то возможный поток программистов/дизайнеров/тестеров даже пока фактически ничего хоть сколько-то конкурентноспособного в системе нет.
Ещё я, пожалуй, за монолит, но учитывая, что готового нормального проекта ядра у меня нет, не особо возражаю против микроядра при условии наличия такого проекта.тупая физическая сила тупо кодить, кодить и кодить. Или и то, и то, что наиболее вероятно.
Но тем не менее да, не позволяет (поддержка PAE тоже даром не даётся). И 64-битность использовать не позволяет, всё верно.
Если что, я не настаиваю на именно таком методе работы - просто мне такой вариант представляется достаточно разумным способом а) продолжать писать на ассемблере, при этом получив и 32-, и 64-битность без необходимости раздувания кода в два раза, б) получить возможность продолжать использовать существующий код, в) несколько сократить объём кода и используемой памяти (32-битный код таки "в целом" короче 64-битного и данных - ну хотя бы стековой памяти под сохранение регистров - требует меньше). Естественно, в случае отказа от этих требований этот вариант превращается в ненужные усложнения, а одним из самых разумных будет, вероятно, уже предложенный вариант попилить ядро линуха
Ещё я, пожалуй, за монолит, но учитывая, что готового нормального проекта ядра у меня нет, не особо возражаю против микроядра при условии наличия такого проекта.
Это, кстати, правда.Mario wrote:Каждый из нас ярый индивидуалист и нет цементирующих факторов.
Насколько я помню, планы мышонка Брейна срывались в основном из-за его не обладающего столь развитым мозгом его коллеги Пинки. Впрочем, сам факт включения этого коллеги во все планы уже говорит о том, что одного высокоразвитого мозга без поддержки коллег таки недостаточно. Или о том, что даже планам высокоразвитого мозга нужно иногда простоMario wrote:и строить фантастические планы подобно мышонку Брейну.
Возможно. Но при сравнении "старый код+новый код" против "новый код+новый код" во втором случае появляется непаханое поле для багов на месте первого слагаемого, которое перевешивает трения на месте знака суммы просто в силу размеров.maximYCH wrote:Имелось ввиду, что связка старого кода и нового кода породит проблемы соответствия и совместимости, отладки и т.д.
Вообще-то в 32-битном режиме можно в одном приложении адресовать до 4G виртуальной памяти, а уже упомянутое PAE спокойно при этом адресует до 64G физической памяти (извраты начинаются, когда всю эту физическую память захочет захапать одно приложение).maximYCH wrote:Ты игнорируешь то, что в 32битном режиме можно адресовать только 4 Гб, а сейчас как раз по 4Гб и ставят, как следствие, будут ставить ещё больше. И юзеру ОС уже выйдет не бесплатно, т.к. ОС не позволяет использовать купленные ресурсы.
Но тем не менее да, не позволяет (поддержка PAE тоже даром не даётся). И 64-битность использовать не позволяет, всё верно.
maximYCH wrote:И вообще, ничего, что простая замена eax-rax и т.д. не есть суть архитектуры? Это ПОЛНОСТЬЮ новая архитектура во многих местах, и игнорировать возможности (учитывая, что это по факту промышленный стандарт) - отказ от будущего.
Отвечаю сразу двоим. x86-64 поддерживает 32-битные сегменты кода. Большая часть кода может просто оставаться 32-битной при том, что вся система в целом будет 64-битной и сможет, в частности, запускать 64-битные приложения. Естественно, менеджер памяти и настройка при загрузке должны быть разными в 32- и 64-битных случаях, но ядро несколько больше, чем упомянутые части.andrew_programmer wrote:А вот насчёт адаптации под 64 бита 70 тысяч строк кода не всё так тривиально...
Собственно, так и совмещать. Сравнительно небольшая часть знает про 64-битность, потому что не может не знать, и создаёт 32-битный сегмент для остальной части ядра, ну а остальная часть просто выполняется в этом сегменте и не подозревает. Выход в 64-битный режим, хоть и отменяет V86, но не требует отказа от 32-битного (и даже 16-битного) кода.andrew_programmer wrote:И возникает вопрос, как совмещать 32-х и 64-х битный код?
Если что, я не настаиваю на именно таком методе работы - просто мне такой вариант представляется достаточно разумным способом а) продолжать писать на ассемблере, при этом получив и 32-, и 64-битность без необходимости раздувания кода в два раза, б) получить возможность продолжать использовать существующий код, в) несколько сократить объём кода и используемой памяти (32-битный код таки "в целом" короче 64-битного и данных - ну хотя бы стековой памяти под сохранение регистров - требует меньше). Естественно, в случае отказа от этих требований этот вариант превращается в ненужные усложнения, а одним из самых разумных будет, вероятно, уже предложенный вариант попилить ядро линуха
Системы бывают не только идеальными и отстойными Колибри - совсем не идеал, но это не означает, что она - отстой, который нужно выкинуть, после чего начать строить светлое будущее, вообще забыв про текущий код.maximYCH wrote:Я тебя не понимаю. То ты пишешь, как все криво, то как все хорошо.
Чем больше я исправляю багов в существующем коде, тем меньше у меня желания а) исправлять баги в новом коде (а они там несомненно будут, ругаться на них тоже несомненно будут, а отладка в этом проекте обычно на мне) и б) тупо выбрасывать существующий код. Так что я за последовательное изменение существующего кода (пусть и включающее в себя значительные перестройки типа перехода на плоское ядро), причём со временем - всё сильнееmaximYCH wrote:Можно немного пояснить логику своих ответов на форуме по этим вопросам?
Ушёл к умным, знающим и культурным людям.
Ладно, вопросы кто чего хочет конкретно - это очень смутные вопросы, судя по всему. Казалось бы и микроядра, и SMP, и ACPI и PnP, но ведь в этом случае придется переписать ядро. Причем каждый думает по своему и мы как древние люди друг друга иногда не понимаем)
Вообщем, что у меня есть относительно идей по ядру:
1) UEFI. Промышленный стандарт, который при содействии Intel (а теперь и MS) внедряется. Позволит заменить старый BIOS со множеством тонкостей (кстати, кто там кричал - BIOS к черту? Дык скоро BIOSа и выбора будет он или нет _в принципе_ не будет) на удобный интерфейс реализации загрузки. Для компов, в которых UEFI нет, использовать его эмулирующую оболочку (благо, такая уже есть, остается только узнавать - есть на компе реальный UEFI и соответственно, использовать эмулирующую оболочку или нет). И не надо кричать "да и без UEFI живем". А Вы смотрите в будущее. Ещё три года назад здесь не было упоминаний о x64 (кроме критики Вилле). Три года назад ещё ни у кого не было таких процессоров практически? А сейчас? у 2/3.
2) Kernel Start Module, KSM. Предлагаю вынести всю инциализацию и подготовку в отдельную программу, которая загружается после UEFI модуля, но до старта ядра. Собирает информацию, в том числе из ACPI, сопоставляет информацию с драйверами, и т.д. Таблица соответствий (ACPI данные - драйвер) сохраняется в памяти, и в дальнейшем используется ядром.
3) Ядро. Обеспечивает только выделение памяти, работу с процессами/потоками, обеспечивает реализацию модели ввода/вывода, управление ресурсами. С изначально заложенным ACPI, PnP, SMP, APIC. Иначе смысл переделок теряется.
Вообщем, что у меня есть относительно идей по ядру:
1) UEFI. Промышленный стандарт, который при содействии Intel (а теперь и MS) внедряется. Позволит заменить старый BIOS со множеством тонкостей (кстати, кто там кричал - BIOS к черту? Дык скоро BIOSа и выбора будет он или нет _в принципе_ не будет) на удобный интерфейс реализации загрузки. Для компов, в которых UEFI нет, использовать его эмулирующую оболочку (благо, такая уже есть, остается только узнавать - есть на компе реальный UEFI и соответственно, использовать эмулирующую оболочку или нет). И не надо кричать "да и без UEFI живем". А Вы смотрите в будущее. Ещё три года назад здесь не было упоминаний о x64 (кроме критики Вилле). Три года назад ещё ни у кого не было таких процессоров практически? А сейчас? у 2/3.
2) Kernel Start Module, KSM. Предлагаю вынести всю инциализацию и подготовку в отдельную программу, которая загружается после UEFI модуля, но до старта ядра. Собирает информацию, в том числе из ACPI, сопоставляет информацию с драйверами, и т.д. Таблица соответствий (ACPI данные - драйвер) сохраняется в памяти, и в дальнейшем используется ядром.
3) Ядро. Обеспечивает только выделение памяти, работу с процессами/потоками, обеспечивает реализацию модели ввода/вывода, управление ресурсами. С изначально заложенным ACPI, PnP, SMP, APIC. Иначе смысл переделок теряется.
diamond
Наверное твоим способом и можно сделать систему 64-х битной. Но я слабо представляю как 32-х битный код ядра будет обрабатывать запросы от 64-х битных приложений. Если только ограничить 64 бита адресным пространством в 4 Гб. В любом случае для работы в long mode потребуются новые обработчики прерываний и переписать всю работу с таблицами страниц. По функциональности и объёму написаный с нуля код для long mode будет близок к микроядру.
Наверное твоим способом и можно сделать систему 64-х битной. Но я слабо представляю как 32-х битный код ядра будет обрабатывать запросы от 64-х битных приложений. Если только ограничить 64 бита адресным пространством в 4 Гб. В любом случае для работы в long mode потребуются новые обработчики прерываний и переписать всю работу с таблицами страниц. По функциональности и объёму написаный с нуля код для long mode будет близок к микроядру.
Что-то у меня сомнения есть по поводу совмещения. Ядро оно либо 64-битное, либо 32-битное. Точно также, как и задача. Одно дело прерывания и syscall/sysenter, и совсем другое jmp и call. Вот как, к примеру, будет выполняться команда ret в 32-битном сегменте? Откуда ей знать, что то, что лежит в стеке 64-битное?diamond wrote:Сравнительно небольшая часть знает про 64-битность, потому что не может не знать, и создаёт 32-битный сегмент для остальной части ядра, ну а остальная часть просто выполняется в этом сегменте и не подозревает.
Этот слоган наиболее ёмко (в 34 байтах) отражает мое личное мнение по самому важному для меня вопросу развития КОС.maximYCH wrote:кстати, кто там кричал - BIOS к черту?
Кому такая плотность упаковки не по зубам - см. Вики/tomorrow.
В любом случае, вырезать из неразрывного смыслового и ассоциативного контекста половину фразы, и вставлять ее в виде маргинальной антитезы в собственное (весьма спорное) утверждение = не уважать ни оппонента, ни себя.
Евангелие от Иоанна: стих 1[/size]
Code: Select all
; В начале было Слово:
B32: mov ax, os_stack ; Selector for os
Serge
Да, это проблема. Можно сделать так: обработчик прерывания от 64-битного приложения сохраняет 64-битные регистры, скажем, на стеке, и передаёт их младшие половины 32-битному коду; если 32-битный код обнаруживает, что ему нужны данные по указателю, то он для маленьких буферов вызывает 64-битный callback, копирующий данные, скажем, опять же в стек, а для больших буферов (ну там, данные чтения/записи для файловой системы) - просто ремаппинг страниц. Правда, при этом получаются какие-то лишние смены разрядности.
tsdima
Межсегментный jmp far вполне себе может передавать управление в то же кольцо защиты, но с другой разрядностью. В пределах одного сегмента, естественно, всё либо 32-, либо 64-битное, так что ret в 32-битном коде всегда возвращается в 32-битный же код.
Да, это проблема. Можно сделать так: обработчик прерывания от 64-битного приложения сохраняет 64-битные регистры, скажем, на стеке, и передаёт их младшие половины 32-битному коду; если 32-битный код обнаруживает, что ему нужны данные по указателю, то он для маленьких буферов вызывает 64-битный callback, копирующий данные, скажем, опять же в стек, а для больших буферов (ну там, данные чтения/записи для файловой системы) - просто ремаппинг страниц. Правда, при этом получаются какие-то лишние смены разрядности.
tsdima
Межсегментный jmp far вполне себе может передавать управление в то же кольцо защиты, но с другой разрядностью. В пределах одного сегмента, естественно, всё либо 32-, либо 64-битное, так что ret в 32-битном коде всегда возвращается в 32-битный же код.
Ушёл к умным, знающим и культурным людям.
diamond
Мне кажется это приведёт к такому количеству ошибок и потребует столько времени на отладку что становится почти невозможным. И это будет очень массивный и сложный костыль.
Менее амбициозная попытка сделать Kolibri PE и то захлебнулась.
Мне кажется это приведёт к такому количеству ошибок и потребует столько времени на отладку что становится почти невозможным. И это будет очень массивный и сложный костыль.
Менее амбициозная попытка сделать Kolibri PE и то захлебнулась.
Не спорю. Тогда придётся для всех public-процедур писать обёртки для вызова их из сегмента с другой разрядностью, которые будут конвертировать параметры и завершаться не ret, а jmp far. На мой взгляд, это костыль ещё тот. Потому, что если будет передаваться указатель, придётся каким-то образом определить размер буфера и копировать этот буфер туда-сюда (или временно мапить его в пространстве вызываемого кода).diamond wrote:Межсегментный jmp far вполне себе может передавать управление в то же кольцо защиты, но с другой разрядностью.
Ну или постоянно мапить, но при выделении памяти из 64-битного пространства указывать, выше или ниже 4Гб нужна память. Главное - корректно описать структуру данных (указатели в 32-битном сегменте будут сопровождаться 32-битным нулевым полем).
Who is online
Users browsing this forum: No registered users and 0 guests