Тех. Задание на Микро-Ядро

No comments
  • Блин ребята, микро ядро хорошо когда пишеш для одной целевой платформы (ARM/Alpha/PPC/ или там атмеловские контроллеры) а отладу производиш на другой (чащё x86), это даёт простоту разработки конкретного решения. При переносе просто выкидываеш что не надо (на целевой платформе как правило мало железа) и получаеш компактный, работаюший код. Из минусов микроядер - низкая производительность по сравнению с монолитными ядрами, из-за частых обращений к микроядру (соответственно и частых переключений контестов). Kolibri - прежде всего ассемблер, и речи о кросс платформенности идти не может. Целевая платформа определена и базовый набор железа тоже. И зачем нам микро ядро? Почиайте теорию, не гоняйтесь за модными словами.
  • Приветствую всех, уважаемые товарисчи !!!

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

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

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

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

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

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

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

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

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

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

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

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

    Продолжение следует...
  • Когда в монолитное ядро вводится подгрузка дополнительных модулей и драйверов - это есть ничто иное как 'первый шаг' в сторону микроядерной архитектуры. Причем этот шаг вызван не прихотью разработчиков, а требованием времени.
    У меня изначально была подгрузка модулей, причем не как один из вариантов, а как единственно возможный вариант, но от этого мое ядро не перестает быть типичным монолитом.
    Выше изложенные попытки IBM и Intel (туда же и Microsoft) рождает в умах многих обывателей такие понятия как 'Стандартнй набор оборудования' , 'Стандартный набор драйверов', 'Стандартный набор приложений' и т.п.

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

    Есть компьютеры в которых нет дисковода, есть компьютеры в которых нет клавиатуры, есть компьютеры в которых нет дисплея, жесткого диска и т.д.
    Дело в том, что я пишу на ассемблере и ориентируюсь на вполне конкретную платформу и вполне конкретный тип машин. Да, я считаю консольные драйверы стандартными и поэтому размещаю их в ядре; да, я планирую расширять поддержку шин, которая также реализуется в ядре. Но это мне не помешало вынести ВСЕ(!) дисковые драйверы, а также драйверы, расширяющие возможности стандартной консоли, в отдельные модули. Естественно, это касается и поддержки более специфичных устройств, которая, правда, пока еще не реализована, т.к. я продолжаю делать упор на развитие ядра.
  • Я согласен с w-tools Если ядро будет развиваться как монолит, пусть даже модульный, оно зайдёт в тупик.
    Конечно микроядро медленнее монолитного но это не означает что оно ползает как черепаха. Перевод Minix3 на микроядро стоил в среднем 12%, В реальной работе когда процессор загружен на 1-2% процента это незаметно.
  • Phantom-84 скоре всего ты(вы) меня не правельно понял !?

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

    Если ты пишеш OS, или уже написал многое, то тебе наверное уже многое известно и многое наработанно.
    Не поленись 'чиркни' пару десятков строк ассемблерного кода на этой ветке в пользу микроядра, загрузчика или бут рекорда и т.д. , и т.п. Пусть этот код будет кривым и неидеальным - другие выпрямят и подправят, глядиш а там целая система выросит...
  • Я не имею ничего против того что ты пишеш OS с монолитным ядром и подгружемыми драйверами. Я наоборот считаю что если человек достиг такого уровня понимания системы это очень здорово!!! Но суть этой ветки форума не 'зарубить' и потом 'закопать' микроядерную систему, а напротив создать(написать) ее !!!
    Да я вовсе не собираюсь "зарубать" и тем более "закапывать" микроядерную систему. Я участвую в этом обсуждении, потому что микроядро мне тоже интересно. Просто ты пытался связать микроядро с модульностью и наоборот, и я тебе возразил. Еще тут речь зашла о порядке загрузки драйверов и я высказал свое мнение, что в микроядерной системе большую часть драйверов следует загружать как можно позже после загрузки ядра, чтобы порядок загрузки базовых драйверов и тех драйверов, которые могут по ходу дела запускаться системой, сделать как можно более схожим (т.е. однообразным). Вариант, когда загрузкой основных драйверов занимается загрузчик ядра (нужно минимизировать количество таких драйверов), не является оптимальным даже в монолитах, что уж говорить о микроядерных системах.
  • 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 не есть далекое будущее !!!

    Продолжение следует ...
  • Я тут продолжаю лоадер писать, пока с этим 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
    Можно сказать, начало уже положено :)
  • 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"(уже теми функциями, адреса которых передали первые драйвера, во время выполнения ихних точек входа, посредством системных вызовов). И эти драйвера, будут выполнять абсолютно тоже самое(Передавать адреса функций посредством системных вызовов).

    Вот вроде и вся базовая модель загрузки драйверов. :)
  • hidden - мои приветствия !!! Вери, вери гуд !!! :-) :-) :-)
    Начало действительно положено !!! :-) :-) :-)

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

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

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

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

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

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

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

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

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

    P.S. Продолжение следует ...
  • Начальный загрузчик это 'мертвый код' нужен только при запуске системы, а затем будет просто занимать лишнюю память. Благодаря разработчикам из IBM и INTEL код начальной загрузки и перевода процессора в P-Mode, включение страничной адресации - относительно большой, кривой и сложный, поэтому весь этот код нужно помаксимуму вынести в начальный загрузчик, а после загрузки системы при необходимости можно просто удалить из памяти начальный загрузчик.
    Т.е. речь уже идет о вторичном загрузчике, hidden же, насколько я понимаю, пытается все разместить в первичном дисковом загрузчике (т.е. в бутсекторе). Вы сначала с этим определитесь. Кстати код, выполняющий первичную инициализацию, вполне может находиться в файле ядра и также спокойно "отбрасываться" после того, как выполнит свою функцию.
    После завершения работы загрузчика, микро ядро (слово микро - понимается в буквальном смысле этого слова) придет уже на готовые куски памяти, в которые загружены драйвера, приложения, или просто массывы данных (буферы). Затем ядро проверит их на целостность по контрольной сумме, включит многозадачный режим, просмотрит свой конфигурационыый файл kernel.cfg и все что предназначается для запуска поставит на исполнение.

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

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

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

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

    Users browsing this forum: No registered users and 8 guests