Board.KolibriOS.org

Official KolibriOS board
It is currently Fri Dec 04, 2020 11:28 am

All times are UTC+03:00




Post new topic  Reply to topic  [ 125 posts ]  Go to page Previous 1 2 3 4 59 Next
Author Message
 Post subject:
PostPosted: Sat Apr 28, 2007 11:44 pm 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Quote:
кстати, никто серьёзно не рассматривал помещение их в первое кольцо как и планировал интел?
Нет. Я же сказал, что являюсь сторонником монолитной архитектуры, т.е. считаю в определенной степени драйверы частью ядра. В моей системе рядовой пользователь не может инициировать загрузку драйвера. Кромо того при загрузке драйверов ядро проверяет их корректность с помощью контрольной суммы. К сбою системы может привести только криво написанный и разрешенный администратором к загрузке драйвер.


Top
   
 Post subject:
PostPosted: Sun Apr 29, 2007 3:58 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 558
Блин ребята, микро ядро хорошо когда пишеш для одной целевой платформы (ARM/Alpha/PPC/ или там атмеловские контроллеры) а отладу производиш на другой (чащё x86), это даёт простоту разработки конкретного решения. При переносе просто выкидываеш что не надо (на целевой платформе как правило мало железа) и получаеш компактный, работаюший код. Из минусов микроядер - низкая производительность по сравнению с монолитными ядрами, из-за частых обращений к микроядру (соответственно и частых переключений контестов). Kolibri - прежде всего ассемблер, и речи о кросс платформенности идти не может. Целевая платформа определена и базовый набор железа тоже. И зачем нам микро ядро? Почиайте теорию, не гоняйтесь за модными словами.


Top
   
 Post subject:
PostPosted: Sun Apr 29, 2007 7:31 pm 
Offline

Joined: Thu Feb 08, 2007 10:17 am
Posts: 54
Приветствую всех, уважаемые товарисчи !!!

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

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

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

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

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

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

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

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

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

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

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

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

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


Top
   
 Post subject:
PostPosted: Sun Apr 29, 2007 11:06 pm 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Quote:
Когда в монолитное ядро вводится подгрузка дополнительных модулей и драйверов - это есть ничто иное как 'первый шаг' в сторону микроядерной архитектуры. Причем этот шаг вызван не прихотью разработчиков, а требованием времени.
У меня изначально была подгрузка модулей, причем не как один из вариантов, а как единственно возможный вариант, но от этого мое ядро не перестает быть типичным монолитом.

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

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

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


Top
   
 Post subject:
PostPosted: Mon Apr 30, 2007 10:49 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Я согласен с w-tools Если ядро будет развиваться как монолит, пусть даже модульный, оно зайдёт в тупик.
Конечно микроядро медленнее монолитного но это не означает что оно ползает как черепаха. Перевод Minix3 на микроядро стоил в среднем 12%, В реальной работе когда процессор загружен на 1-2% процента это незаметно.


Top
   
 Post subject:
PostPosted: Mon Apr 30, 2007 6:37 pm 
Offline

Joined: Thu Feb 08, 2007 10:17 am
Posts: 54
Phantom-84 скоре всего ты(вы) меня не правельно понял !?

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

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


Top
   
 Post subject:
PostPosted: Mon Apr 30, 2007 8:12 pm 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Quote:
Я не имею ничего против того что ты пишеш OS с монолитным ядром и подгружемыми драйверами. Я наоборот считаю что если человек достиг такого уровня понимания системы это очень здорово!!! Но суть этой ветки форума не 'зарубить' и потом 'закопать' микроядерную систему, а напротив создать(написать) ее !!!
Да я вовсе не собираюсь "зарубать" и тем более "закапывать" микроядерную систему. Я участвую в этом обсуждении, потому что микроядро мне тоже интересно. Просто ты пытался связать микроядро с модульностью и наоборот, и я тебе возразил. Еще тут речь зашла о порядке загрузки драйверов и я высказал свое мнение, что в микроядерной системе большую часть драйверов следует загружать как можно позже после загрузки ядра, чтобы порядок загрузки базовых драйверов и тех драйверов, которые могут по ходу дела запускаться системой, сделать как можно более схожим (т.е. однообразным). Вариант, когда загрузкой основных драйверов занимается загрузчик ядра (нужно минимизировать количество таких драйверов), не является оптимальным даже в монолитах, что уж говорить о микроядерных системах.


Top
   
 Post subject:
PostPosted: Tue May 01, 2007 11:11 am 
Offline

Joined: Thu Feb 08, 2007 10:17 am
Posts: 54
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 не есть далекое будущее !!!

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


Top
   
 Post subject:
PostPosted: Tue May 01, 2007 9:34 pm 
Я тут продолжаю лоадер писать, пока с этим FAT12 разбирался, теперь думаю куда грузить корневую директорию, чтоб она там не мешалась.)))
Code:
;*******************************************************************************
; 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
Можно сказать, начало уже положено :)


Top
   
 Post subject:
PostPosted: Tue May 01, 2007 10:08 pm 
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"(уже теми функциями, адреса которых передали первые драйвера, во время выполнения ихних точек входа, посредством системных вызовов). И эти драйвера, будут выполнять абсолютно тоже самое(Передавать адреса функций посредством системных вызовов).

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


Top
   
 Post subject:
PostPosted: Wed May 02, 2007 9:24 am 
Offline

Joined: Thu Feb 08, 2007 10:17 am
Posts: 54
hidden - мои приветствия !!! Вери, вери гуд !!! :-) :-) :-)
Начало действительно положено !!! :-) :-) :-)

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

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

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

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

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

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

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

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

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

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


Top
   
 Post subject:
PostPosted: Wed May 02, 2007 10:28 am 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Quote:
Начальный загрузчик это 'мертвый код' нужен только при запуске системы, а затем будет просто занимать лишнюю память. Благодаря разработчикам из IBM и INTEL код начальной загрузки и перевода процессора в P-Mode, включение страничной адресации - относительно большой, кривой и сложный, поэтому весь этот код нужно помаксимуму вынести в начальный загрузчик, а после загрузки системы при необходимости можно просто удалить из памяти начальный загрузчик.
Т.е. речь уже идет о вторичном загрузчике, hidden же, насколько я понимаю, пытается все разместить в первичном дисковом загрузчике (т.е. в бутсекторе). Вы сначала с этим определитесь. Кстати код, выполняющий первичную инициализацию, вполне может находиться в файле ядра и также спокойно "отбрасываться" после того, как выполнит свою функцию.

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

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


Top
   
 Post subject:
PostPosted: Wed May 02, 2007 10:38 am 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Quote:
Адресацию исполняемого файла предлагаю вести с нулевого адреса без смещения (думаю страничная адресация позволит это сделать)
У меня это именно так, но умные люди подсказали, что в начале адресного пространства должен существовать стоп-фрейм (размером в 1 страничку или сразу в 4 мега) для перехвата обращений по нулевому адресу, т.к. именно этот адрес часто возвращают различные функции для сигнализирования о какой-либо ошибке.

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

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


Top
   
 Post subject:
PostPosted: Wed May 02, 2007 11:33 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
w-tools

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


Top
   
 Post subject:
PostPosted: Wed May 02, 2007 3:56 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
P.S.

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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 125 posts ]  Go to page Previous 1 2 3 4 59 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