Моя позиция по поводу предназначения - десктопы. Обоснование: на "серьёзные" объекты неизвестную ОСь просто не пустят, так что перспективы в отношении серверов, равно как и встраиваемых систем, исключительно туманны. На собственный десктоп, по крайней мере, поставить "на посмотреть" может практически кто угодно из продвинутых ITшников, что даёт какую-то известность и какой-то возможный поток программистов/дизайнеров/тестеров даже пока фактически ничего хоть сколько-то конкурентноспособного в системе нет.
Ещё я, пожалуй, за монолит, но учитывая, что готового нормального проекта ядра у меня нет, не особо возражаю против микроядра при условии наличия такого проекта.
Mario wrote:Каждый из нас ярый индивидуалист и нет цементирующих факторов.
Это, кстати, правда.
Mario wrote:и строить фантастические планы подобно мышонку Брейну.
Насколько я помню, планы мышонка Брейна срывались в основном из-за его не обладающего столь развитым мозгом его коллеги Пинки. Впрочем, сам факт включения этого коллеги во все планы уже говорит о том, что одного высокоразвитого мозга без поддержки коллег таки недостаточно. Или о том, что даже планам высокоразвитого мозга нужно иногда просто
тупая физическая сила тупо кодить, кодить и кодить. Или и то, и то, что наиболее вероятно.
maximYCH wrote:Имелось ввиду, что связка старого кода и нового кода породит проблемы соответствия и совместимости, отладки и т.д.
Возможно. Но при сравнении "старый код+новый код" против "новый код+новый код" во втором случае появляется непаханое поле для багов на месте первого слагаемого, которое перевешивает трения на месте знака суммы просто в силу размеров.
maximYCH wrote:Ты игнорируешь то, что в 32битном режиме можно адресовать только 4 Гб, а сейчас как раз по 4Гб и ставят, как следствие, будут ставить ещё больше. И юзеру ОС уже выйдет не бесплатно, т.к. ОС не позволяет использовать купленные ресурсы.
Вообще-то в 32-битном режиме можно в одном приложении адресовать до 4G
виртуальной памяти, а уже упомянутое PAE спокойно при этом адресует до 64G
физической памяти (извраты начинаются, когда всю эту физическую память захочет захапать одно приложение).
Но тем не менее да, не позволяет (поддержка PAE тоже даром не даётся). И 64-битность использовать не позволяет, всё верно.
maximYCH wrote:И вообще, ничего, что простая замена eax-rax и т.д. не есть суть архитектуры? Это ПОЛНОСТЬЮ новая архитектура во многих местах, и игнорировать возможности (учитывая, что это по факту промышленный стандарт) - отказ от будущего.
andrew_programmer wrote:А вот насчёт адаптации под 64 бита 70 тысяч строк кода не всё так тривиально...
Отвечаю сразу двоим. x86-64 поддерживает 32-битные сегменты кода. Большая часть кода может просто оставаться 32-битной при том, что вся система в целом будет 64-битной и сможет, в частности, запускать 64-битные приложения. Естественно, менеджер памяти и настройка при загрузке должны быть разными в 32- и 64-битных случаях, но ядро несколько больше, чем упомянутые части.
andrew_programmer wrote:И возникает вопрос, как совмещать 32-х и 64-х битный код?
Собственно, так и совмещать. Сравнительно небольшая часть знает про 64-битность, потому что не может не знать, и создаёт 32-битный сегмент для остальной части ядра, ну а остальная часть просто выполняется в этом сегменте и не подозревает. Выход в 64-битный режим, хоть и отменяет V86, но не требует отказа от 32-битного (и даже 16-битного) кода.
Если что, я не настаиваю на именно таком методе работы - просто мне такой вариант представляется достаточно разумным способом а) продолжать писать на ассемблере, при этом получив и 32-, и 64-битность без необходимости раздувания кода в два раза, б) получить возможность продолжать использовать существующий код, в) несколько сократить объём кода и используемой памяти (32-битный код таки "в целом" короче 64-битного и данных - ну хотя бы стековой памяти под сохранение регистров - требует меньше). Естественно, в случае отказа от этих требований этот вариант превращается в ненужные усложнения, а одним из самых разумных будет, вероятно, уже предложенный вариант попилить ядро линуха
maximYCH wrote:Я тебя не понимаю. То ты пишешь, как все криво, то как все хорошо.
Системы бывают не только идеальными и отстойными
Колибри - совсем не идеал, но это не означает, что она - отстой, который нужно выкинуть, после чего начать строить светлое будущее, вообще забыв про текущий код.
maximYCH wrote:Можно немного пояснить логику своих ответов на форуме по этим вопросам?
Чем больше я исправляю багов в существующем коде, тем меньше у меня желания а) исправлять баги в новом коде (а они там несомненно будут, ругаться на них тоже несомненно будут, а отладка в этом проекте обычно на мне) и б) тупо выбрасывать существующий код. Так что я за последовательное изменение существующего кода (пусть и включающее в себя значительные перестройки типа перехода на плоское ядро), причём со временем - всё сильнее