Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Сб дек 16, 2017 12:33 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 292 сообщения ]  На страницу Пред. 13 4 5 6 720 След.
Автор Сообщение
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Ср янв 27, 2010 7:30 pm 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
ладно, каждый думает, как хочет (мы можем долго спорить, но от основной темы мы и так отвлеклись). Но, что я знаю точно и проверил на собственной шкуре: НИКТО не будет делать ничего в сторону встроенных решений кроме Вас, если САМ того не захочет. В сообщении #33, Вы высказали свою позицию, и я должен Вас разочаровать: на собственной шкуре понял, что в этом проекте каждый сам по себе. И заставлять людей (эксплуатировать) просто не возможно, у Вас это не получится. Ну а то, что Вы высказали свою позицию - отлично. Поэтому собственно я до сих пор не вижу проблем с embedded.


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Чт янв 28, 2010 7:26 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
maximYCH писал(а):
Сейчас в ядре ~30 000 кода.

Общее число строк во всех файлах *.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 писал(а):
Казалось бы, ядро тогда будет в порядке, т.к. основное переписали. НЕ БУДЕТ. Старый код будет глючить в связке с новым, и будет куча проблем.

Любой код будет глючить в той или иной степени, и нет оснований считать, что старый код будет глючить больше просто потому, что он старый. Собственно, есть подозрение, что, наоборот, новый код будет глючить сильнее просто в силу того, что из текущего кода глюки старательно выбиваются уже несколько лет :)
Mario писал(а):
На уровне хобби проекта развитие очень медленное, так как мало ресурсов. Как коммерческая система тоже не тянет - нет спроса. Можно конечно сто раз написать как все можно сделать замечательно и почему до этого это все не было сделано, но по сути ничего не меняется. Эффект Linux нам не повторить. По этой причине я лично вижу только путь коммерческого развития. Давайте честно признаемся сами себе - что выделять даже 30 минут в сутки в среднем получается пока есть энтузиазм, а он как показывает практика достаточно быстро заканчивается.

Как это ни странно, на уровне хобби развитие вполне себе идёт, хоть и мало ресурсов. И даже дошло до указанных выше ~70000 строк (оно, конечно, понятно, что не в строчках кода счастье, но как один из показателей годится). Так что и без коммерческого развития дела будут идти и дальше.
andrew_programmer писал(а):
Я тоже об этом думал. Микроядро на чистом ассемблере. А "обвес" хочешь на C, не любишь C, так ассемблер. Это единственный способ снизить зависимость от: x86-32/SMP, x86-64/SMP. А иначе возьмут Intel и AMD, и придумают какую нибудь Asymmetric Multi Processors с кучей ядер, и придётся всё заново переделывать.

Архитектура x86-64 вполне себе совместима с x86. Текущая 32-битная Колибри вполне себе работает на 64-битных процессорах, хотя и не используя 64-битность как таковую. Пример Menuet64 показывает, что можно относительно малыми силами сделать и 64-битность, оставаясь в рамках ассемблера. Так что заявления, что "придётся всё заново переделывать", представляют из себя слишком сильное преувеличение.
andrew_programmer писал(а):
Некоторых от C, а уж тем более от AT&T синтаксиса встроенного ассемблера вообще выворачивает наизнанку.

AT&T синтаксис ассемблера не имеет к Си как таковому ни малейшего отношения.
Mario писал(а):
Хорошо будем ковыряться дальше в песочнице.

Угу. Пока что ковыряние привело к, по крайней мере, работающей системе.

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Чт янв 28, 2010 7:35 pm 
Ну, вот на форуме появился Главный и расставил все точки над Ы... :lol:


Вернуться к началу
   
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Чт янв 28, 2010 7:42 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Mario писал(а):
От людей можно что-либо требовать лишь поставив их в зависимость - например ЗП, наличие определенных привилегий, можно еще к затылку приставить пистолет, т.е. угрозой расправы, других способов человечество не придумало.

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

Во-первых, я тут не Главный или, точнее, не единственный Главный, ещё Serge есть :) Во-вторых, я только в процессе чтения этой флудильниживо всех волнующей и, как следствие, растущей с необычно высокой скоростью темы, так что точки ещё не все...

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Чт янв 28, 2010 8:01 pm 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
Цитата:
Любой код будет глючить в той или иной степени, и нет оснований считать, что старый код будет глючить больше просто потому, что он старый. Собственно, есть подозрение, что, наоборот, новый код будет глючить сильнее просто в силу того, что из текущего кода глюки старательно выбиваются уже несколько лет

Имелось ввиду, что связка старого кода и нового кода породит проблемы соответствия и совместимости, отладки и т.д.
Цитата:
Архитектура x86-64 вполне себе совместима с x86. Текущая 32-битная Колибри вполне себе работает на 64-битных процессорах, хотя и не используя 64-битность как таковую. Пример Menuet64 показывает, что можно относительно малыми силами сделать и 64-битность, оставаясь в рамках ассемблера. Так что заявления, что "придётся всё заново переделывать", представляют из себя слишком сильное преувеличение.

Ты игнорируешь то, что в 32битном режиме можно адресовать только 4 Гб, а сейчас как раз по 4Гб и ставят, как следствие, будут ставить ещё больше. И юзеру ОС уже выйдет не бесплатно, т.к. ОС не позволяет использовать купленные ресурсы. И вообще, ничего, что простая замена eax-rax и т.д. не есть суть архитектуры? Это ПОЛНОСТЬЮ новая архитектура во многих местах, и игнорировать возможности (учитывая, что это по факту промышленный стандарт) - отказ от будущего.
Цитата:
Угу. Пока что ковыряние привело к, по крайней мере, работающей системе.

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


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Чт янв 28, 2010 8:08 pm 
Не в сети
Аватара пользователя

Зарегистрирован: Чт май 19, 2005 4:43 pm
Сообщения: 896
Цитата:
Архитектура x86-64 вполне себе совместима с x86. Текущая 32-битная Колибри вполне себе работает на 64-битных процессорах, хотя и не используя 64-битность как таковую. Пример Menuet64 показывает, что можно относительно малыми силами сделать и 64-битность, оставаясь в рамках ассемблера. Так что заявления, что "придётся всё заново переделывать", представляют из себя слишком сильное преувеличение.

То что совмести - это спасибо AMD. А вот насчёт адаптации под 64 бита 70 тысяч строк кода не всё так тривиально... Отсутствие режима virtual86, добавление 8 новых 64 битных регистров общего назначения, и 8 новых xmm8-xmm15 регистров, изменяется размер и адреса переменных в памяти. Вместо mov eax,[ecx*8+4] будет mov rax,[rcx*16+8]. И возникает вопрос, как совмещать 32-х и 64-х битный код? Писать 2 версии алгоритмов, увеличивая в 2 раза объём работы? А если ещё SMP учесть.... Лично мне нужна максимальна производительность от всех ядер процессора и всех регистров. Численное моделирование этого требует.
Цитата:
AT&T синтаксис ассемблера не имеет к Си как таковому ни малейшего отношения.

Ключевое слово встроенного ассемблера. Ибо добавляется %0,%1...,а также "r=","m","r","g",.... куча всяких особенностей чем должен заменить компилятор gcc соответствующий символ(регистр, переменная, константа и т.д.).

_________________
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Чт янв 28, 2010 9:08 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Моя позиция по поводу предназначения - десктопы. Обоснование: на "серьёзные" объекты неизвестную ОСь просто не пустят, так что перспективы в отношении серверов, равно как и встраиваемых систем, исключительно туманны. На собственный десктоп, по крайней мере, поставить "на посмотреть" может практически кто угодно из продвинутых ITшников, что даёт какую-то известность и какой-то возможный поток программистов/дизайнеров/тестеров даже пока фактически ничего хоть сколько-то конкурентноспособного в системе нет.
Ещё я, пожалуй, за монолит, но учитывая, что готового нормального проекта ядра у меня нет, не особо возражаю против микроядра при условии наличия такого проекта.
Mario писал(а):
Каждый из нас ярый индивидуалист и нет цементирующих факторов.

Это, кстати, правда.
Mario писал(а):
и строить фантастические планы подобно мышонку Брейну.

Насколько я помню, планы мышонка Брейна срывались в основном из-за его не обладающего столь развитым мозгом его коллеги Пинки. Впрочем, сам факт включения этого коллеги во все планы уже говорит о том, что одного высокоразвитого мозга без поддержки коллег таки недостаточно. Или о том, что даже планам высокоразвитого мозга нужно иногда просто тупая физическая сила тупо кодить, кодить и кодить. Или и то, и то, что наиболее вероятно.
maximYCH писал(а):
Имелось ввиду, что связка старого кода и нового кода породит проблемы соответствия и совместимости, отладки и т.д.

Возможно. Но при сравнении "старый код+новый код" против "новый код+новый код" во втором случае появляется непаханое поле для багов на месте первого слагаемого, которое перевешивает трения на месте знака суммы просто в силу размеров.
maximYCH писал(а):
Ты игнорируешь то, что в 32битном режиме можно адресовать только 4 Гб, а сейчас как раз по 4Гб и ставят, как следствие, будут ставить ещё больше. И юзеру ОС уже выйдет не бесплатно, т.к. ОС не позволяет использовать купленные ресурсы.

Вообще-то в 32-битном режиме можно в одном приложении адресовать до 4G виртуальной памяти, а уже упомянутое PAE спокойно при этом адресует до 64G физической памяти (извраты начинаются, когда всю эту физическую память захочет захапать одно приложение).
Но тем не менее да, не позволяет (поддержка PAE тоже даром не даётся). И 64-битность использовать не позволяет, всё верно.
maximYCH писал(а):
И вообще, ничего, что простая замена eax-rax и т.д. не есть суть архитектуры? Это ПОЛНОСТЬЮ новая архитектура во многих местах, и игнорировать возможности (учитывая, что это по факту промышленный стандарт) - отказ от будущего.

andrew_programmer писал(а):
А вот насчёт адаптации под 64 бита 70 тысяч строк кода не всё так тривиально...

Отвечаю сразу двоим. x86-64 поддерживает 32-битные сегменты кода. Большая часть кода может просто оставаться 32-битной при том, что вся система в целом будет 64-битной и сможет, в частности, запускать 64-битные приложения. Естественно, менеджер памяти и настройка при загрузке должны быть разными в 32- и 64-битных случаях, но ядро несколько больше, чем упомянутые части.
andrew_programmer писал(а):
И возникает вопрос, как совмещать 32-х и 64-х битный код?

Собственно, так и совмещать. Сравнительно небольшая часть знает про 64-битность, потому что не может не знать, и создаёт 32-битный сегмент для остальной части ядра, ну а остальная часть просто выполняется в этом сегменте и не подозревает. Выход в 64-битный режим, хоть и отменяет V86, но не требует отказа от 32-битного (и даже 16-битного) кода.

Если что, я не настаиваю на именно таком методе работы - просто мне такой вариант представляется достаточно разумным способом а) продолжать писать на ассемблере, при этом получив и 32-, и 64-битность без необходимости раздувания кода в два раза, б) получить возможность продолжать использовать существующий код, в) несколько сократить объём кода и используемой памяти (32-битный код таки "в целом" короче 64-битного и данных - ну хотя бы стековой памяти под сохранение регистров - требует меньше). Естественно, в случае отказа от этих требований этот вариант превращается в ненужные усложнения, а одним из самых разумных будет, вероятно, уже предложенный вариант попилить ядро линуха :)
maximYCH писал(а):
Я тебя не понимаю. То ты пишешь, как все криво, то как все хорошо.

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

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

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Чт янв 28, 2010 9:29 pm 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
Ладно, вопросы кто чего хочет конкретно - это очень смутные вопросы, судя по всему. Казалось бы и микроядра, и 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. Иначе смысл переделок теряется.


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Чт янв 28, 2010 11:42 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
diamond

Наверное твоим способом и можно сделать систему 64-х битной. Но я слабо представляю как 32-х битный код ядра будет обрабатывать запросы от 64-х битных приложений. Если только ограничить 64 бита адресным пространством в 4 Гб. В любом случае для работы в long mode потребуются новые обработчики прерываний и переписать всю работу с таблицами страниц. По функциональности и объёму написаный с нуля код для long mode будет близок к микроядру.


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Пт янв 29, 2010 12:11 am 
Не в сети

Зарегистрирован: Ср мар 26, 2008 12:44 pm
Сообщения: 85
diamond писал(а):
Сравнительно небольшая часть знает про 64-битность, потому что не может не знать, и создаёт 32-битный сегмент для остальной части ядра, ну а остальная часть просто выполняется в этом сегменте и не подозревает.

Что-то у меня сомнения есть по поводу совмещения. Ядро оно либо 64-битное, либо 32-битное. Точно также, как и задача. Одно дело прерывания и syscall/sysenter, и совсем другое jmp и call. Вот как, к примеру, будет выполняться команда ret в 32-битном сегменте? Откуда ей знать, что то, что лежит в стеке 64-битное?


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Пт янв 29, 2010 12:39 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
maximYCH писал(а):
кстати, кто там кричал - BIOS к черту?

Этот слоган наиболее ёмко (в 34 байтах) отражает мое личное мнение по самому важному для меня вопросу развития КОС.

Кому такая плотность упаковки не по зубам - см. Вики/tomorrow.

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

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Пт янв 29, 2010 12:59 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Serge
Да, это проблема. Можно сделать так: обработчик прерывания от 64-битного приложения сохраняет 64-битные регистры, скажем, на стеке, и передаёт их младшие половины 32-битному коду; если 32-битный код обнаруживает, что ему нужны данные по указателю, то он для маленьких буферов вызывает 64-битный callback, копирующий данные, скажем, опять же в стек, а для больших буферов (ну там, данные чтения/записи для файловой системы) - просто ремаппинг страниц. Правда, при этом получаются какие-то лишние смены разрядности.
tsdima
Межсегментный jmp far вполне себе может передавать управление в то же кольцо защиты, но с другой разрядностью. В пределах одного сегмента, естественно, всё либо 32-, либо 64-битное, так что ret в 32-битном коде всегда возвращается в 32-битный же код.

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Пт янв 29, 2010 2:51 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3929
diamond

Мне кажется это приведёт к такому количеству ошибок и потребует столько времени на отладку что становится почти невозможным. И это будет очень массивный и сложный костыль.
Менее амбициозная попытка сделать Kolibri PE и то захлебнулась.


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Пт янв 29, 2010 11:25 am 
Не в сети

Зарегистрирован: Ср мар 26, 2008 12:44 pm
Сообщения: 85
diamond писал(а):
Межсегментный jmp far вполне себе может передавать управление в то же кольцо защиты, но с другой разрядностью.

Не спорю. Тогда придётся для всех public-процедур писать обёртки для вызова их из сегмента с другой разрядностью, которые будут конвертировать параметры и завершаться не ret, а jmp far. На мой взгляд, это костыль ещё тот. Потому, что если будет передаваться указатель, придётся каким-то образом определить размер буфера и копировать этот буфер туда-сюда (или временно мапить его в пространстве вызываемого кода).


Вернуться к началу
 Заголовок сообщения: Re: Новая ветка ядра
СообщениеДобавлено: Пт янв 29, 2010 11:46 am 
Не в сети

Зарегистрирован: Ср мар 26, 2008 12:44 pm
Сообщения: 85
Ну или постоянно мапить, но при выделении памяти из 64-битного пространства указывать, выше или ниже 4Гб нужна память. Главное - корректно описать структуру данных (указатели в 32-битном сегменте будут сопровождаться 32-битным нулевым полем).


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 292 сообщения ]  На страницу Пред. 13 4 5 6 720 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 2 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB