Page 3 of 9

Posted: Sat Apr 28, 2007 11:44 pm
by Phantom-84
кстати, никто серьёзно не рассматривал помещение их в первое кольцо как и планировал интел?
Нет. Я же сказал, что являюсь сторонником монолитной архитектуры, т.е. считаю в определенной степени драйверы частью ядра. В моей системе рядовой пользователь не может инициировать загрузку драйвера. Кромо того при загрузке драйверов ядро проверяет их корректность с помощью контрольной суммы. К сбою системы может привести только криво написанный и разрешенный администратором к загрузке драйвер.

Posted: Sun Apr 29, 2007 3:58 pm
by Ghost
Блин ребята, микро ядро хорошо когда пишеш для одной целевой платформы (ARM/Alpha/PPC/ или там атмеловские контроллеры) а отладу производиш на другой (чащё x86), это даёт простоту разработки конкретного решения. При переносе просто выкидываеш что не надо (на целевой платформе как правило мало железа) и получаеш компактный, работаюший код. Из минусов микроядер - низкая производительность по сравнению с монолитными ядрами, из-за частых обращений к микроядру (соответственно и частых переключений контестов). Kolibri - прежде всего ассемблер, и речи о кросс платформенности идти не может. Целевая платформа определена и базовый набор железа тоже. И зачем нам микро ядро? Почиайте теорию, не гоняйтесь за модными словами.

Posted: Sun Apr 29, 2007 7:31 pm
by w-tools
Приветствую всех, уважаемые товарисчи !!!

Почему многие из вас, так 'узко' смотрят на понятие 'оборудование' и понятие 'операционная' система ???
Поясню свою мысль:

Многие говорят 'Монолитное Ядро' - это значит что в состав ядра жестко входит определенное количество драйверов. Тогда с ростом количества драйверов (оборудования), монолитное ядро обречено на 'чрезмерное разбухание' и в конечном итоге неизбежная 'смерть' от ожирения :-)
На эти 'грабли' в свое время наступил Linux, и чтобы избавиться от 'передания' была вмонтированна система модульной подгрузки драйверов. В конечном итоге получилась очень монстровая и сложная для понимания система, а поддержка архаичных требований POSIX приводит программиста в системе Linux в состояние полного 'мозгового коллапса' (кто пытался написать что нибудь серьезное и нетривиальное под Linux поймут очем идет речь)

Фатальная ошибка Minix - Minix3 это продолжние линни по поддержке архаичных требований POSIX и банальное игнорирование новых введений типа UNICOD и прочих требований современной действительности.

Когда в монолитное ядро вводится подгрузка дополнительных модулей и драйверов - это есть ничто иное как 'первый шаг' в сторону микроядерной архитектуры. Причем этот шаг вызван не прихотью разработчиков, а требованием времени.

Дальнейшее развитие и усовершенствование модульной подгрузки драйверов неизбежно приводит к постоению микроядерной системы, причем этот поцесс ничто иное как 'эволюция' опрерационных систем.

Когда разработчики из IBM всеми силами пытаются в одну маленькую материнскую плату втиснуть так называемый 'стандартный комплект оборудования', который постоянно обновляется и расширяется, они - раработчики IBM - очередной раз разбрасывают на своем пути грабли на которые в последствии будут обречены обязательно наступить. Разработчикам из IBM и Intel гораздо разумне былобы избавитьмя от своего 'сарого хлама' и создать уневерсальную универсальную асинхронную шину, только не такую мудреную и сложную как шина PCI.

Выше изложенные попытки IBM и Intel (туда же и Microsoft) рождает в умах многих обывателей такие понятия как 'Стандартнй набор оборудования' , 'Стандартный набор драйверов', 'Стандартный набор приложений' и т.п.

А что озноначает это слово 'Стандартный' ???
Слово 'Стандартный' на самом деле ничего не значит !!!

Есть компьютеры в которых нет дисковода, есть компьютеры в которых нет клавиатуры, есть компьютеры в которых нет дисплея, жесткого диска и т.д.
Есть огромная масса различного нового оборудования для которых тоже нужны драйвера !!!
Есть не мение огромная масса самодельного, отладочного, лабораторного, исследовательского, эксперементального или просто собранная энтузиастами своими рукамии с помрщью простого паяльника и пинцета - оригинального и не менее интересного оборудования !!!

Так что понятие 'стандартное' ограничено лиш узким кругозором обывателя.
(Например в соседней лаборатории стоит голая материнка I486 c дисководом и Com портом и подключенная к ней через ISA эксперементальная установка, все это работает под MS-DOS. Пограммисты и техники матеряться на кривость архитектуры памяти и убогость системы, но уних нет выхода и они продолжают использвать что есть под рукой. И таких ситуаций десятки тысяч по стране и милионы по всему миру)

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

P.S. Пожалуиста побольше 'кода' и по возможности меньше 'флейма' !!!

Продолжение следует...

Posted: Sun Apr 29, 2007 11:06 pm
by Phantom-84
Когда в монолитное ядро вводится подгрузка дополнительных модулей и драйверов - это есть ничто иное как 'первый шаг' в сторону микроядерной архитектуры. Причем этот шаг вызван не прихотью разработчиков, а требованием времени.
У меня изначально была подгрузка модулей, причем не как один из вариантов, а как единственно возможный вариант, но от этого мое ядро не перестает быть типичным монолитом.
Выше изложенные попытки IBM и Intel (туда же и Microsoft) рождает в умах многих обывателей такие понятия как 'Стандартнй набор оборудования' , 'Стандартный набор драйверов', 'Стандартный набор приложений' и т.п.

А что озноначает это слово 'Стандартный' ???
Слово 'Стандартный' на самом деле ничего не значит !!!

Есть компьютеры в которых нет дисковода, есть компьютеры в которых нет клавиатуры, есть компьютеры в которых нет дисплея, жесткого диска и т.д.
Дело в том, что я пишу на ассемблере и ориентируюсь на вполне конкретную платформу и вполне конкретный тип машин. Да, я считаю консольные драйверы стандартными и поэтому размещаю их в ядре; да, я планирую расширять поддержку шин, которая также реализуется в ядре. Но это мне не помешало вынести ВСЕ(!) дисковые драйверы, а также драйверы, расширяющие возможности стандартной консоли, в отдельные модули. Естественно, это касается и поддержки более специфичных устройств, которая, правда, пока еще не реализована, т.к. я продолжаю делать упор на развитие ядра.

Posted: Mon Apr 30, 2007 10:49 am
by Serge
Я согласен с w-tools Если ядро будет развиваться как монолит, пусть даже модульный, оно зайдёт в тупик.
Конечно микроядро медленнее монолитного но это не означает что оно ползает как черепаха. Перевод Minix3 на микроядро стоил в среднем 12%, В реальной работе когда процессор загружен на 1-2% процента это незаметно.

Posted: Mon Apr 30, 2007 6:37 pm
by w-tools
Phantom-84 скоре всего ты(вы) меня не правельно понял !?

Я не имею ничего против того что ты пишеш OS с монолитным ядром и подгружемыми драйверами. Я наоборот считаю что если человек достиг такого уровня понимания системы это очень здорово!!! Но суть этой ветки форума не 'зарубить' и потом 'закопать' микроядерную систему, а напротив создать(написать) ее !!!

Если ты пишеш OS, или уже написал многое, то тебе наверное уже многое известно и многое наработанно.
Не поленись 'чиркни' пару десятков строк ассемблерного кода на этой ветке в пользу микроядра, загрузчика или бут рекорда и т.д. , и т.п. Пусть этот код будет кривым и неидеальным - другие выпрямят и подправят, глядиш а там целая система выросит...

Posted: Mon Apr 30, 2007 8:12 pm
by Phantom-84
Я не имею ничего против того что ты пишеш OS с монолитным ядром и подгружемыми драйверами. Я наоборот считаю что если человек достиг такого уровня понимания системы это очень здорово!!! Но суть этой ветки форума не 'зарубить' и потом 'закопать' микроядерную систему, а напротив создать(написать) ее !!!
Да я вовсе не собираюсь "зарубать" и тем более "закапывать" микроядерную систему. Я участвую в этом обсуждении, потому что микроядро мне тоже интересно. Просто ты пытался связать микроядро с модульностью и наоборот, и я тебе возразил. Еще тут речь зашла о порядке загрузки драйверов и я высказал свое мнение, что в микроядерной системе большую часть драйверов следует загружать как можно позже после загрузки ядра, чтобы порядок загрузки базовых драйверов и тех драйверов, которые могут по ходу дела запускаться системой, сделать как можно более схожим (т.е. однообразным). Вариант, когда загрузкой основных драйверов занимается загрузчик ядра (нужно минимизировать количество таких драйверов), не является оптимальным даже в монолитах, что уж говорить о микроядерных системах.

Posted: Tue May 01, 2007 11:11 am
by w-tools
Phantom-84
Особой разницы на каком этапе грузить драйвера нет. Если говорить более точно то оба способа загрузки драйверов должны быть и качественно работать. Например если мы грузимся с сетевой карты и у нас нет ни дисковода ни винчестера то имеет смысл загрузить драйвера начальным загрузчиком, а после запуска ядра догрузить необходимые драйвера из интернета. Или наоборот в некоторых случаях будет иметь смысл загрузить начальным загрузчиком только драйвер HDD, а затем после запуска ядра, shell(или что нибудь типа него) догрузит все необходимые драйвера.
Короче говоря оба способа должны работать на 'отлично' и выбор того или иного способа будет определять сам пользователь ориентируясь на свою ситуацию.

В одном из предыдущих постов hidden привел отрывки асемблерного кода которые переключают процессор в защищенный режим и включают линию A20.
Phantom-84 не поленись дополни этот код своим кодом (наработками) и оформи это в обычный досовый файл 'loader.com'. Пусть этот loader.com выводит на экран 'Hello Word !!!'
Таким образом начало для написания начального загрузчика будет положенно !!!

Если Serg или Ghost дополнят этот loader.com 'страничной организацией',а Mario79 встроит функцию работы с дисководом в защищенном режиме, то можно будет считать что минимально ниобходимый начальный загрузчик написан.

Возможно ктото уже 'ковырнул' бут рекорд у MeOs, тогда прописав в этот бут рекорд загрузку loder.com можно будет полнофункционально грузиться с дискеты.
А дальше можно будет создавать и без особых проблем грузить микроядро ядро и драйвера !!!
Тем более судя по этому форуму многие уже пытаются перестроить организацию системных вызовов в Kolibri, так что микро ядро точно не загорами !!!

Причем собрав микроядро, под ним можно будет запускать MeOs, Kolibri, Linux и много чего другого !!!

P.S. Товарисчи пожалуиста не ленитесь, 'выкладывайте' свои наработки !!!
Общая структура (модель) микроядерной архитектуры выложена в моем первом посте и собрав 'с миру по нитке' придерживаясь этой структуры микроядерная OS не есть далекое будущее !!!

Продолжение следует ...

Posted: Tue May 01, 2007 9:34 pm
by hidden
Я тут продолжаю лоадер писать, пока с этим FAT12 разбирался, теперь думаю куда грузить корневую директорию, чтоб она там не мешалась.)))

Code: Select all

;*******************************************************************************
; Static variables
;*******************************************************************************
LOADER_BASE	= 0x7C00
MAX_LOADER_SIZE = 512
MAX_CONFIG_SIZE = 0x1000

	org	LOADER_BASE
	use16
;*******************************************************************************
	jmp	short boot_code
	nop
;*******************************************************************************
; FAT12 section
;*******************************************************************************
virtual at $
  dbOEM 	db 'NYAOS1.0'		    ; OEM String
  dwSectSize	dw 512			    ; Bytes per sector
  dbClustSize	db 1			    ; Sectors per cluster
  dwResSect	dw 1			    ; # of reserved sectors
  dbFATCopies	db 2			    ; # of fat copies
  dwRootEntries dw 224			    ; # of root directory entries
  dwTotalSect	dw 2880 		    ; total # of sectors if < 32 meg
  dbMedia	db 0xF0 		    ; Media Descriptor
  dwSect%FAT	dw 9			    ; Sectors per FAT
  dwSect%Track	dw 18			    ; Sectors per track
  dwHeadNum	dw 2			    ; # of read-write heads
  ddHiddenSects dd 0			    ; # of hidden sectors
  ddHugeSect	dd 0			    ; if bsTotalSect is 0 this value is
					    ; the number of sectors
  dbBootDrive	db 0			    ; holds drive that the bs came from
  dbReserv	db 0			    ; not used for anything
  dbBootSign	db 29h			    ; boot signature 29h
  ddVolID	dd 0			    ; Disk volume ID also used for temp
					    ; sector # / # sectors to load
  dbVoLabel	db '           '	    ; Volume Label
  dbFSType	db 'FAT12   '		    ; File System type
  dwEnd 	dw 7DF1h
  svLen 	= $ - dbOEM
end virtual
file 'bootimg.img':dbOEM - LOADER_BASE,svLen
;*******************************************************************************
; Boot code begins
;*******************************************************************************
  boot_code:
	jmp	0x0:start
  start:
	cli				; Запрещаем маскируемые прерывания

;*******************************************************************************
	in	al, 0x70		; Запрещаем не маскируемые прерывания
	mov	bl, al
	or	al, 10000000b		; Ставим 8й бит
	out	70h , al		; RTC после записи байта в порт 0х70
	in	al, 0x71		; ожидают обращения к порту 0x71

;*******************************************************************************
	in	al, 0x92		; открываем адресную линию A20
	or	al, 2
	out	0x92, al

;*******************************************************************************
	mov	[dbBootDrive], dl	  ; save drive number
	xor	ax, ax			; Предпологется что 32-х битное
					; расширение и так равно нулю
	mov	es, ax			; Устанавливаем ss и ss в 0
	mov	ss, ax
	mov	sp, LOADER_BASE
	mov	di, LOADER_BASE + 512  ; Буффер для GDT сразу за образом

;*******************************************************************************
; Initializing unreal mode
;*******************************************************************************
	;shl     eax, 4
	;add     eax, edi
	;push    eax
	push	edi			; Сохраняем его
; Нудевой дескриптор
	;xor     eax, eax
	stosd
	stosd
; Плоский дескриптор
	or	ax, -1
	stosd
	mov	eax, 0x00CF9200 	; Флаги плоского дескриптора
	stosd

	push	8 * 2			; Длина GDT для загрузки в GDTR
	lgdt	[esp]
	add	sp, 6

	mov	eax, cr0		; Включаем PM (Protected mode)
	or	al, 1
	mov	cr0, eax

	mov	dx, 8			; Cмещение плоского элемента GDT
	mov	ds, dx			; Загружаем все сигментные регистры
	mov	es, dx
	;mov     ss, dx
	;mov     gs, dx
	;mov     fs, dx

	and	al, not 1
	mov	cr0, eax		; Отключаем PM

	sti				; Разрешаем маскируемые прерывания

	mov	al, bl			; Разрешаем не маскируемые прерывания
	out	0x70, al
	in	al, 0x71

	mov	dx, 92h
	in	al, dx
	or	al, 2
	out	dx, al

;*******************************************************************************
; Читаем boot.cfg
;*******************************************************************************
	mov	bx, LOADER_BASE + 512 + 512
        mov      cx, [dwRootEntries]    ; dwRootEntries
                                        ; *EntriesSize{32} /dwSectSize{512}
        shr      cx, 4                  ; << 5{*32} >> 9{/512} = >> 4{/16}

        xor     eax, eax
        mov     al, [dbFATCopies]
        mul     [dwSect%FAT]
        add     eax, [ddHiddenSects]
        add     ax, [dwResSect]         ; ax holds root directory location

        call    readsect

        mov     bx, LOADER_BASE + 512 + 512
        mov     al, [ds:bx]
        call    print_al

        ; ................................
        ; ................................
        ; ................................
        ; ................................

  exit:
        ;jmp     $
        xor     ah, ah
	int	16h			; Ожидаем нажатия любой клавиши

  error:
        jmp     exit

;*******************************************************************************
; Вспомогательные функции
;*******************************************************************************
  print_al: ; Использую временно, как отладчик
	push	eax
	xor	ah, ah
	ror	eax, 4
	call	print_hex_char
	shr	eax, 32 - 4
	call	print_hex_char
	mov	al, ' '
	int	10h
	pop	eax
	ret
  print_hex_char:
	cmp	al, 10
	sbb	al, 69h
	das
	mov	ah, 0x0E
	int	10h
	ret

;*******************************************************************************
; es:bx = Location, ax = Sector
;*******************************************************************************
  readsect:   ; es:bx = Location, ax = Sector
	push	ax cx
	;xor     dx, dx
	cwd				; for floppy
	div	[dwSect%Track]		; divide logical sect by track size
	inc	dl			; sector # begins at 1
	mov	[dbReserv], dl		; sector to read
	mov	cl, dl
	cwd				; logical track left in ax
	div	[dwHeadNum]		; leaves head in dl, cyl in ax
	mov	dh, [dbBootDrive]
	xchg	dl, dh			; head to dh, drive to dl
	mov	cx, ax			; cyl to cx
	xchg	cl, ch			; low 8 bits of cyl to ch, hi 2 bits
	shl	cl, 6			; shifted to bits 6 and 7
	or	cl, [dbReserv]		; or with sector number
	mov	ax, 0x0201		; Read{0x02} one{0x01} sector
	int	0x13			; read sector
	jc	error			; display error message
	pop	cx ax
	ret				; return to caller

;*******************************************************************************
; Lets end up boot sector
;*******************************************************************************
if $ > LOADER_BASE + MAX_LOADER_SIZE
  'Error: MAX_LOADER_SIZE excepted'
end if

;*******************************************************************************
		rb 512 - 2 - $ + $$	; Заполняем оставшееся
		db 0x55, 0xAA		; the signature itself

;*******************************************************************************
; This's the end of the boot sector
;*******************************************************************************

  ; Это образ дискеты с файлом boot.cfg и ещё несколькими.
  file 'bootimg.img':MAX_LOADER_SIZE,$168000 - MAX_LOADER_SIZE

virtual at LOADER_BASE + MAX_LOADER_SIZE
  boot.cfg	rb MAX_CONFIG_SIZE	; Буффер для чтения файла конфигурации
   .len 	rd 1
  ;bDrive        rd 1
end virtual
Можно сказать, начало уже положено :)

Posted: Tue May 01, 2007 10:08 pm
by hidden
w-tools wrote:В одном из предыдущих постов hidden привел отрывки асемблерного кода которые переключают процессор в защищенный режим и включают линию A20.
Phantom-84 не поленись дополни этот код своим кодом (наработками) и оформи это в обычный досовый файл 'loader.com'. Пусть этот loader.com выводит на экран 'Hello Word !!!'
Эти отрывки переводят его в "Unreal Mode", к нему нелюзя прикрутить страничную организацию, для перехода в "Protected Mode", потребовалось бы гораздо больше кода, а прерывания БИОС перестали бы быть доступны.

Почему я считаю, что переход в "Protected Mode", должен осуществляться ядром? Потому, что ядру по любому нужно будет оперировать с GDT и IDT, а значит и выделать для них память, заполнять их элементы, можно к примеру как лоадер закончит загрузку ядра и всего остального, сново отключить все прерывания, поставить первый бит в cr0, и прыгнуть в ядро, при таком раскладе ядру не придётся использовать 16битные инструкции, во время выделения памяти, и заполнения таблиц, но включать страничную адресацию в загрузчике, это ИМХО уже слишком.

Когда ядро полностью инициализирует Защищённый Режим, установит обработчики прерываний, включит страничную адресацию, подготовит менеджер памяти, вот тогда уже начнёт вызывать точки входа в драйвера, предварительно сверяя их контрольные суммы с файлом "kernel.cfg", вот здесь и будет выявлены ошибки загрузки, не отягощая лоадер. Когда будут выполнены все точки входа, во все драйвера, загруженные загрузчиком, ядро проверит, достаточно ли ему функций для работы и если достаточно, продолжит загружать и выполнять остальные драйвера, из файла "kernel.cfg"(уже теми функциями, адреса которых передали первые драйвера, во время выполнения ихних точек входа, посредством системных вызовов). И эти драйвера, будут выполнять абсолютно тоже самое(Передавать адреса функций посредством системных вызовов).

Вот вроде и вся базовая модель загрузки драйверов. :)

Posted: Wed May 02, 2007 9:24 am
by w-tools
hidden - мои приветствия !!! Вери, вери гуд !!! :-) :-) :-)
Начало действительно положено !!! :-) :-) :-)

Теперь о технических деталях :

Загрузчик должен сначало первести процессор в P-Mode, затем обязательно настроить
страничную адресацию, затем выделять при помощи страничной адресации куски памяти и заносить в эти куски наши драйвера и приложения по конфигурационному файлу на загрузку. Это действительно немного усложнит начальный загрузчик, но всеравно он останется маленьким и компактным. Такое решение позволит обойти много трудностей и облегчит затем программистам и драверописателям жизнь. Короче говоря позволит 'убить несколько зайцев одним выстрелом' :-) Поясню подробнее:

Начальный загрузчик это 'мертвый код' нужен только при запуске системы, а затем будет просто занимать лишнюю память. Благодаря разработчикам из IBM и INTEL код начальной загрузки и перевода процессора в P-Mode, включение страничной адресации - относительно большой, кривой и сложный, поэтому весь этот код нужно помаксимуму вынести в начальный загрузчик, а после загрузки системы при необходимости можно просто удалить из памяти начальный загрузчик.

После завершения работы загрузчика, микро ядро (слово микро - понимается в буквальном смысле этого слова) придет уже на готовые куски памяти, в которые загружены драйвера, приложения, или просто массывы данных (буферы). Затем ядро проверит их на целостность по контрольной сумме, включит многозадачный режим, просмотрит свой конфигурационыый файл kernel.cfg и все что предназначается для запуска поставит на исполнение.

Микро Ядро по своей сути самодостаточный модуль, и для своей работы ему не требуется ни один файл или драйвер, для передачи начальных параметров и правильного запуска приложений микро ядру требуется только конфигурационный файл kernel.cfg и то это в принципе не обязательно !!! (по умолчанию без конфигурационного файла микроядро запустит все исполняемые файлы которые обнаружет в памяти)

Начальный загрузчик действительно получится немного сложней, но это затем слихвой окупится.
Вопревых мы почти полностью избавимся от шеснадцатиричного кода в начальном загрузчике, тем самым создадим готовый полигон для начальной проверки и отладки оборудования в 32-х разрядном режиме, но без многозадачности - которая как правило на начальном этапе создания какого либо драйвера только мешает.
Включив в загрузчик страничную адресацию и набор блоков памяти из страниц, мы максимально унифицируем процесс загрузки драйверов и приложений в память как начальным загрузчиком так и загрузчиком который будет загружать файлы после старта микро ядра. Затем этим уже готовым кодом смогут воспользоваться все те кто будет писать Shell, Far или какойнибудь шедуллер.
Написав в начальном загрузчике код для работы с дисководом, дисплеем, клавиатурой и т.д
мы облегчим жизь драйверо писателям, которые смогут воспользоваться уже готовыми наработками.

И как я уже отмечал выше loadеr.com будет отличным полигоном для начального создания драйверов в 32х разрядном режиме.

Забегая далеко в перед, скажу что минимальный размер исплняемого файла будет 4kb и кнему автоматически должен прикручиваться минимальный стек размером тоже в 4kb (конечно его можно будет потом увеличить).
Адресацию исполняемого файла предлагаю вести с нулевого адреса без смещения (думаю страничная адресация позволит это сделать)
первая команда будет длинный jmp (он же будет обязательным идентификатором исполняемого файла), затем будут находиться всякие параметры.
Не исполняемые файлы - куски данных в памяти будут тоже начинатьс с нулевого адреса и иметь в качестве первого двойного слова нули (обязательный идентификатор неисполняемого файла)

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

P.S. Продолжение следует ...

Posted: Wed May 02, 2007 10:28 am
by Phantom-84
Начальный загрузчик это 'мертвый код' нужен только при запуске системы, а затем будет просто занимать лишнюю память. Благодаря разработчикам из IBM и INTEL код начальной загрузки и перевода процессора в P-Mode, включение страничной адресации - относительно большой, кривой и сложный, поэтому весь этот код нужно помаксимуму вынести в начальный загрузчик, а после загрузки системы при необходимости можно просто удалить из памяти начальный загрузчик.
Т.е. речь уже идет о вторичном загрузчике, hidden же, насколько я понимаю, пытается все разместить в первичном дисковом загрузчике (т.е. в бутсекторе). Вы сначала с этим определитесь. Кстати код, выполняющий первичную инициализацию, вполне может находиться в файле ядра и также спокойно "отбрасываться" после того, как выполнит свою функцию.
После завершения работы загрузчика, микро ядро (слово микро - понимается в буквальном смысле этого слова) придет уже на готовые куски памяти, в которые загружены драйвера, приложения, или просто массывы данных (буферы). Затем ядро проверит их на целостность по контрольной сумме, включит многозадачный режим, просмотрит свой конфигурационыый файл kernel.cfg и все что предназначается для запуска поставит на исполнение.

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

Posted: Wed May 02, 2007 10:38 am
by Phantom-84
Адресацию исполняемого файла предлагаю вести с нулевого адреса без смещения (думаю страничная адресация позволит это сделать)
У меня это именно так, но умные люди подсказали, что в начале адресного пространства должен существовать стоп-фрейм (размером в 1 страничку или сразу в 4 мега) для перехвата обращений по нулевому адресу, т.к. именно этот адрес часто возвращают различные функции для сигнализирования о какой-либо ошибке.
Забегая далеко в перед, скажу что минимальный размер исплняемого файла будет 4kb и кнему автоматически должен прикручиваться минимальный стек размером тоже в 4kb (конечно его можно будет потом увеличить).
Адресацию исполняемого файла предлагаю вести с нулевого адреса без смещения (думаю страничная адресация позволит это сделать)
первая команда будет длинный jmp (он же будет обязательным идентификатором исполняемого файла), затем будут находиться всякие параметры.
Не исполняемые файлы - куски данных в памяти будут тоже начинатьс с нулевого адреса и иметь в качестве первого двойного слова нули (обязательный идентификатор неисполняемого файла)

В общем нужно все упрощать по максимуму, чтобы было красиво, просто и понятно.
Не следует все упрощать до примитивизма! Опять-таки даже у меня, хотя я и использую свой собственный, достаточно простой формат, содержимое файла не является точной копией образа памяти.

Posted: Wed May 02, 2007 11:33 am
by Serge
w-tools

Не мучайся, возьми загрузчик из Колибри. На unreal mode особо расчитывать не стоит. Он работает не везде и не всегда. Наконец в каком режиме будет работать система, текстовом или графическом ? Перейти в графический режим можно только через вызов БИОС, видеодрайверов ожидать не стоит.

Posted: Wed May 02, 2007 3:56 pm
by Serge
P.S.

Дом начинают строить с фундамента, а ты строишь крыльцо со ступеньками, загрузчик для безъядерной операционной системы, потому что никакого ядра нет и в помине, нет даже представления о том как это ядро будет устроено и как будет работать. Список желаемых функций ядра ещё не ядро. Куда это ядро должно грузиться, по каким адресам ? Как будут передаваться параметры при системных вызовах и данные между разными адресными пространствами ? Как вообще эти пространства будут устроены ?