Asmxygen
Websvn
Builds
Bugs
FTP
Wiki
Telegram
Discord
RedditКакие именно ?Ты опять забываешь про дефолтные драйверы, которые на самом деле отдельно.
"Ночные" сборки KolibriOS
Те которые ты предложил "паковать и встраивать" в ядро, это получается шаг назад.
Нет, мне на самом деле РД тоже очень мешает - не влезает в ROM. Но если его убирать - тогда ведь тоже нужна релокация ядерных структур.Mario wrote:Ага, изобретаем опять костыль.
Какая разница - вверх на полтора мега или вниз ?- все равно ядро вылетает...
йес;Serge wrote:Дефолтный курсор встроен в ядро. Почему не встроить туда дефолтные шрифты ?
йес++;Serge wrote:Если драйвер всегда загружается вполне допустимый вариант.
--Ну и фиг с ней!Serge wrote:А вот большая страница никому не мешает, а экономит TLB.
Ради экономии 2..3кб (пусть и в кэше) замутили какую-то неведомую_ех.
До сих пор багов ловим. И новых сажаем.
Мне теперь вопрос на миллион задать? 
"Ху ис мистерПу экзикютер?"
"Ху ис мистер
art_zh
И где там баги с большой страницей ?
Mario
У нас таких драйверов пока нет. Что-нибудь где-нибудь не работает.
Хотя можно встроить ps2 мышь. Но не вижу здесь шага назад потому что включается упакованный бинарник а не исходники. Если например я изменю загрузочный сектор и буду грузить kernel.bin в котором собраны kernel.mnt, шрифты, драйверы и CPU + несколько библиотек это не так сильно будет отличаться от теперешней загрузки RD.
И где там баги с большой страницей ?
Mario
У нас таких драйверов пока нет. Что-нибудь где-нибудь не работает.
Хотя можно встроить ps2 мышь. Но не вижу здесь шага назад потому что включается упакованный бинарник а не исходники. Если например я изменю загрузочный сектор и буду грузить kernel.bin в котором собраны kernel.mnt, шрифты, драйверы и CPU + несколько библиотек это не так сильно будет отличаться от теперешней загрузки RD.
Serge, art_zh: поддерживаю. relocatable-ядро - путь в будущее! 
Кроссмаппинг системной области всегда будет оставаться потенциальным источником багов.Serge wrote:И где там баги с большой страницей ?
Если к одним и тем же физическим адресам можно обратиться (допустим) по линейным адресам 803С0000 (за пределами таблиц, но все еще в Большой странице) и (допустим) 80412000 (хз где в системной куче, точные адреса зависят от длины статической области ядра), причем этот механизм специально внедрен в ядро для экономии кусочка одной TLB - тут могут быть очень разные варианты багов.
art_zh
Если только баг процессора. В документации я ничего такого не находил.
Единственное ограничение - должны совпадать флаги кеширования страницы.
У меня была мысль замапить часть памяти в ядре 1:1, чтобы линейный_адрес = физический+OS_BASE и выделять из неё страницы для таблиц страниц и страничных каталогов. Это упростило бы некоторые оперции в ядре, но лень взяла верх.
Если только баг процессора. В документации я ничего такого не находил.
Единственное ограничение - должны совпадать флаги кеширования страницы.
У меня была мысль замапить часть памяти в ядре 1:1, чтобы линейный_адрес = физический+OS_BASE и выделять из неё страницы для таблиц страниц и страничных каталогов. Это упростило бы некоторые оперции в ядре, но лень взяла верх.
Тут недавно проскакивал вопрос о скринсервере. Моё мнение - текущий скринсервер отстой. Я вообще раньше думал, что это он у меня неправильно работает и ерунду рисует, оказалось так и должно быть. Лучше бы через определённое время простоя рапускался бы "crownscr" и завершался по движению мышью (не сложно реализовать).
Я когда-то скачал его Виндовую версию и юзал, мои друзья приходили и были в шоке как круто - с этим, я думаю, никто не поспорит. Экономия места и приличный скринсервер - как идея?
Я когда-то скачал его Виндовую версию и юзал, мои друзья приходили и были в шоке как круто - с этим, я думаю, никто не поспорит. Экономия места и приличный скринсервер - как идея?
Из хаоса в космос
Это плохая идея. Более того - эта идея отстой.
@SS - 64 Кб занимаемого ОЗУ
CROWNSCR - 705 Кб занимаемого ОЗУ
И это не считая того что CROWNSCR загружает CPU гораздо сильнее (очень близко к 100%) - "приятный" такой подарок владельцам ноутбуков (особенно когда аккумулятор не первой свежести).
@SS - 64 Кб занимаемого ОЗУ
CROWNSCR - 705 Кб занимаемого ОЗУ
И это не считая того что CROWNSCR загружает CPU гораздо сильнее (очень близко к 100%) - "приятный" такой подарок владельцам ноутбуков (особенно когда аккумулятор не первой свежести).
имхо, но заставка вообще не нужна - прошло время выгорания мониторов
А чем grub-то не угодил? Он грузит ядро и модули... в модули можно класть хоть шрифты, хоть драйвера. Фантом в модуле грузит корневые классы виртуальной машины, например.Mario wrote:Ага, изобретаем опять костыль.
Рамдиск изначально должен быть опцией при загрузке, нужно - есть, ненужно - память свободна. В конечном счете можно образ загрузить, уже когда ядро вышло на основной режим работы, в виде первого приложения. Вопрос в продумывании механизма передачи данных -откуда загрузить. По сути пока мешает только то что системные шрифты получается неоткуда подгрузить, да еще драйверы - опять приходим к идее полноценного вторичного загрузчика. Хотя может можно и без него, хз - думать надо.
dzavalishin
У Колибри несколько разных вариантов загрузки (в т.ч. 2 бездисковых), из них GRUB - не самый быстрый и удобный.
У Колибри несколько разных вариантов загрузки (в т.ч. 2 бездисковых), из них GRUB - не самый быстрый и удобный.
dzavalishin
Исторические причины. Когда Ville начал делать Menuet GRUB не был так популярен.
Исторические причины. Когда Ville начал делать Menuet GRUB не был так популярен.
Serge, а проблему с адресами памяти в ядре решили? Я про тот баг, что я нашел, когда сделал загрузочный экран.
Who is online
Users browsing this forum: No registered users and 31 guests