Board.KolibriOS.org

Official KolibriOS board
It is currently Wed Dec 11, 2019 12:33 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 455 posts ]  Go to page Previous 1 2 3 4 5 631 Next
Author Message
 Post subject:
PostPosted: Wed May 17, 2006 6:13 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Хочу пояснить свою позицию по поводу загрузчика.
Я хочу, чтобы загрузчик был достаточно универсален, чтобы его можно было использовать не только с этим ядром и не только с этой системой. Похоже, что проблема загрузки достаточно актуальна для многих осестроителей. Пусть будет загрузчик полезный не только нам но и возможно кому-то ещё. "Лишний" код можно всегда удалить, а возможность работать с файлами, определять устройства, менять настройки никому не помешает.


Top
   
 Post subject:
PostPosted: Wed May 17, 2006 8:05 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
При этом никто не мешает другим осестроителям ещё и использовать наши бутсекторы для разных ФС (и mtldr с acroboot)...


Top
   
 Post subject:
PostPosted: Wed May 17, 2006 8:09 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
При этом никто не мешает другим осестроителям ещё и использовать наши бутсекторы для разных ФС (и mtldr с acroboot)...
Вот и я о том же. Пусть код будет максимально гибким и полезным не только для нас.


Top
   
 Post subject:
PostPosted: Thu May 18, 2006 10:40 am 
Offline
Just Flooding
User avatar

Joined: Wed May 18, 2005 10:27 am
Posts: 430
Serge wrote:
А удастся запихнуть write_file в бутсектор? Конечно так можно сделать, но такое компромисное решение только маскирует проблему. И как быть если хочется держать систему не на С:\ а где нибудь на E:\OS\KOLIBLI\MAIN\053 ?

Я не пойму что то "великий смысл" работы с файлом(и) сразу из бут сектора??? В чем кроется столь высокая стратегия и приоритетность этого? Почему ЭТО нельзя отложить "на потом", скажем на этап полноценного ДРАЙВЕРНОГО взаимодействия системы ну типа расклада как в СТУПЕНИ 3!? Ведь надо делать(мое убеждение), как проще и оптимальнее рашается задача проектирования и работы(функционирование) самого детища, а НЕ так, как хочется проектанту, оператору, юзеру, приложению:), потому, что с каждой колокольни найдутся свои доводы и аргументы, что проще, да приятнее, да удобнее... Плюс нужно не забывать про глобальное видение перспектив выбранной стратегии вцелом, гибкость и пр.
Если хочется E:\OS\KOLIBLI\MAIN\053 то это решаемо именно в бутсекторе. Этому аргумент один, аналогия, как в математике - приведение к ОБЩЕМУ ЗНАМЕНАТЕЛЮ принципов загрузки с различных носителей, FS. Тем самым спрямляется все в одну линию т.к. бутсектор, каков бы он ни был по конструкции, алгоритму, типу FS, ВСЕГДА в конечном итоге загружает один и тот же файл, одно и то же имя файла! Никакой записи! Только ЗАГРУЗКА, точная и прицельная, из каталога ли или нет с одним вложением папок или более, но КОНЕЦ этого этапа= НАЧАЛУ т.к. файл ДОЛЖЕН БЫТЬ найден и успешно загружен в нужную, ФИКСИРОВАННУЮ точку в памяти первых 640кБ! А вот что будет дальше - это следующий шаг, ЭТАП(тут надо не забывать про передачу параметров от бутсектора, хотя бы в регистрах, коих масса и они НАПРАСТНО НИЧЕГО НЕ НЕСУТ ИНФОРМАЦИОННО в этот следующий этап.). Практически и алгоритмически опробовал тучу вариантов подобных решений и путей загрузки, скажу, что путь для ОС более чем x:\xxxxx\<имя файла> - неоправдан ввиду массы причин, поверьте на слово. Посему я "играюсь" с унифицированнным целевым именем ОСи=каталога, а версия, релиз, редакция, модификация предполагает изменение ЕГО расширения (сугубо 8+3) т.е. например:
С:\ATOMOS.000, С:\ATOMOS.001,С:\ATOMOS.023..... Алгоритм решения задачи (код бутсектора) максимально прост и лаконичен, а вот эффект максимален + наглядность(при сортировках) и простота выбора в корне диска, навигация. Это также хорошо и просто даже для правки РУЧКАМИ кода бута в HIEW, например! Это еще один "убитый заяц одним выстрелом". Поправить в HEX-редакторе последние символы - вот тебе новая загрузка, навый путь, навая отладочная редакция! Клонирование таких загрузок -пара пустяков в пределах одного диска даже ДЛЯ МУЛЬТИЗАГРУЗЧИКОВ ОСей, т.к. в их SAVEфайлах все аналогично! И в случае краха или непредвиденных обстоятельств, такой метод успешно работает и позволяет восстановить, вернуться, изменить... На мой комплексный взгляд - одни зайцы! ;D т.е. достоинства.
Если я изъяснился мутно и непонятно где то - не молчите. Всегда готов разжевать и донести суть. Хотелось бы понять и Ваши АРГУМЕНТЫ в этом деле.


Top
   
 Post subject:
PostPosted: Thu May 18, 2006 11:47 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
Если хочется E:\OS\KOLIBLI\MAIN\053 то это решаемо именно в бутсекторе. Этому аргумент один,
Будет сложно грузить E:\OS\KOLIBLI\MAIN\053\kernel.mnt именно бусектором. Бутсектор не знает заранее путь. Значит этот путь должен быть или жестко зашит в код бутсектора или записан в ini файле в корневом каталоге загрузочного диска и бутсектор должен сначала считать этот ini файл. Сомневаюсь, влезет ли весь необходимый для этого код вместе с разбором пути и чтением папок в маленький бутсектор.
Потому и предлагаю свалить всю эту работу на загрузчик.

Всем
Нужно ли ограничивать размер кучи ядра? Например если в системе 64Мб то после загрузки ядра свободно будет 52Мб. Можно делить эту память между ядром и программами как 2/5 (близко к золотому сечению) то есть максимальный размер кучи ядра будет 20 Мб. Для 256 Мб соответственно 96 Мб. Это значение можно переопределять в ini файле например KERNEL HEAP 48 если нужно изменить соотношение.


Top
   
 Post subject:
PostPosted: Thu May 18, 2006 12:02 pm 
Думаю куча ядра и приложений должна быть общая. Разве что для ядра нужно оставлять 2-3% свободной памяти в качестве резерва.


Top
   
 Post subject:
PostPosted: Thu May 18, 2006 2:54 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Резерв оставлять нужно, но речь идет о куче в адресном пространстве ядра, то есть общей памяти. Сюда будут загружаться драйверы ядра, отображаться ввод/вывод и т.д. В общем это память которая будет использоваться только ядром. Это не рельная физическая память, а только диапазон адресов. А у каждой программы будет своя куча в адресном пр-ве приложения.


Top
   
 Post subject:
PostPosted: Thu May 18, 2006 11:00 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
ВсемНужно ли вводить приоритеты для процессов. Если да, то сколько уровней делать и какой алгоритм планирования использовать?


Top
   
 Post subject:
PostPosted: Thu May 18, 2006 11:33 pm 
Offline

Joined: Mon May 01, 2006 10:12 pm
Posts: 349
Приоритеты полюбому нужны
Я тут думал о возможности создания многопотоного сервера и пришёл к такому выводу

Надо как минимум 3(idle-time,real-time,normal)
Для долгих но не критичных можно по времени задач можно добавить belowe normal
Ну и можно above normal (для симметрии :) )
Куда ещё прикручивать не знаю

В алгоритмах планирования я не силён :)


Top
   
 Post subject:
PostPosted: Fri May 19, 2006 8:22 am 
Offline

Joined: Fri Nov 12, 2004 3:20 pm
Posts: 90
По загрузке: возлагать на бутсектор функции загрузки файлов - это ещё нормально, но вот чтобы писать в произвольные файлы... А что, если загрузка идёт с CD, к примеру?

Получается такая схема загрузки:
1. Бутсектор грузит
а) драйвер ФС реального режима (если он не влезает в бутсектор)
б) начальный загрузчик ядра и передаёт ему управление
2. В реальном режиме определяется оборудование, загружаются драйверы дисков и ФС защищенного режима. Загружается ядро, система переводится в защищенный режим и управление переходит на следующую ступень.
3. Загрузчик защищенного режима переходит к страничной адресации, инициализирует драйверы дисков и ФС, после этого загружает остальные драйверы и вперёд в многозадачность! :-)
Загрузчики могут находится как в одном файле с ядром, так и в отдельных.

По поводу кучи ядра: я не понимаю, в чём проблема. Предлагается делить физическую память или виртуальную???
Смысла в первом я не вижу. Во втором тоже :) - память уже разделена. 2 Гб процессу и 2 Гб ядру (или как-нибудь по-другому - не важно).

Я уже создавал тему про Scheduler, но конкретных предложений по алгоритму высказано не было. Реализовать очереди с приоритетами легко, а вот как эти приоритеты назначать... Сам я в этом так и не разобрался.

Да, кстати, лучше не сваливать всё в одну тему, а то бардак получается!


Top
   
 Post subject:
PostPosted: Fri May 19, 2006 10:51 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
По поводу кучи ядра: я не понимаю, в чём проблема. Предлагается делить физическую память или виртуальную???
Смысла в первом я не вижу. Во втором тоже Smile - память уже разделена. 2 Гб процессу и 2 Гб ядру (или как-нибудь по-другому - не важно).
Память ядра общая для всех процессов. Проще создать таблицы страниц для этой памяти сразу, тогда при выделении памяти в ядре нет необходимости проходить по каталогам таблиц всех процессов и модифицировать их. Если в компьютере установлено 64Мб памяти то максимум требуется 16 таблиц страниц (одна таблица на 4Мб ОЗУ). Реально ядро никогда не сможет использовать все 64Мб (часть памяти займут приложения) значит одна или несколько таблиц страниц ядра не будут использоваться. Установив размер кучи ядра можно уменьшить количество таблиц страниц, создаваемых при инициализации системы и сэкономить физическую память.


Top
   
 Post subject:
PostPosted: Sat May 20, 2006 12:58 pm 
Таблицы страниц составляют лишь 0.1%-1% памяти, никто их не заметит.


Top
   
 Post subject:
PostPosted: Sat May 20, 2006 2:49 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Serge,если под ядро отводить (2/5) от общей памяти,то при большом объёме оперативки(512 например) ядру отводиться >200
.А зачем ядру так много? Мы же динамические библиотеки будем грузить в адресное пространство приложений,а не ядра(ато повесим систему к чёрту).Да и драйверы будут не в ядре,а ввиде динамических библиотек.
Это при малом объёме памяти(<256) такой подход правилен.Я думаю,что,если оперативки >256,то нужно под ядро отводить 1/5 часть от общей памяти.


Top
   
 Post subject:
PostPosted: Sat May 20, 2006 5:04 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
erge,если под ядро отводить (2/5) от общей памяти,то при большом объёме оперативки(512 например) ядру отводиться >200
.А зачем ядру так много?
Пока незачем, но если там размещать звуковые буферы, кэш файловой системы, те буферы которые пока размещаются статически то может понадобиться несколько десятков мегабайт. Я сделал в ini параметр Kernel heap. Им можно жёстко задавать размер кучи, а 2/5 или 1/5 использовать только по умолчанию. В любом случае какое-то регулирование размера кучи необходимо.


Top
   
 Post subject:
PostPosted: Wed May 24, 2006 10:34 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Есть два варианта выделения памяти для программ. Первый использует простой односвязный список и хранит все данные в таблицах страниц. Второй сложнее но ему нужна дополнительная память для хранения информации о выделенных блоках памяти. Надо ли использовать более сложный вариант я не знаю. Скорее всего память будет выделятся только один раз при инициализации malloc и дальше все динамическое выделение памяти будет идти через malloc.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 455 posts ]  Go to page Previous 1 2 3 4 5 631 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited