Why The Use Of Kernel System

[Nathan]

Hello,
I'm starting in Assembly and OS development, but i use Linux and have experience with Java(All variations, like Java ME, EE...), C++ and Ruby, because of this things and so much more because of Linux i know many things about Kernel, but like me that haves a very very simple OS, it's a good time to think in the development of an kernel to it and if it is, where i can find some good tutorials, because i this time i'm reading this for kernel(Just to know): http://www.brokenthorn.com/Resources/OSDev11.html, but here is my OS, it's in the beginning, but i'm developing it since 1 day:

Code: Select all

[BITS 16]	     ; 16 bit code generation
[ORG 0x7C00]	 ; ORGin location is 7C00

JMP short main   ; Jump past disk description section
NOP              ; Pad out before disk description

; ------------------------------------------------------------------
; Disk description table, to make it a valid floppy
; Note: some of these values are hard-coded in the source!
; Values are those used by IBM for 1.44 MB, 3.5" diskette

OEMLabel            db "BERL OS"    ; Disk label - 8 chars
BytesPerSector      dw 512          ; Bytes per sector
SectorsPerCluster   db 1            ; Sectors per cluster
ReservedForBoot     dw 1            ; Reserved sectors for boot record
NumberOfFats        db 2            ; Number of copies of the FAT
RootDirEntries      dw 224          ; Number of entries in root dir
LogicalSectors      dw 2880         ; Number of logical sectors
MediumByte          db 0F0h         ; Medium descriptor byte
SectorsPerFat       dw 9            ; Sectors per FAT
SectorsPerTrack     dw 18           ; Sectors per track (36/cylinder)
Sides               dw 2            ; Number of sides/heads
HiddenSectors       dd 0            ; Number of hidden sectors
LargeSectors        dd 0            ; Number of LBA sectors
DriveNo             dw 0            ; Drive No: 0
Signature           db 41           ; Drive signature: 41 for floppy
VolumeID            dd 00000000h    ; Volume ID: any number
VolumeLabel         db "BERL OS"    ; Volume Label: any 11 chars
FileSystem          db "FAT12"      ; File system type: don't change!

; End of the disk description table
; ------------------------------------------------------------------

main:
MOV BH, 00h
MOV BL, 07h
MOV AL, 1
MOV BH, 0
MOV BL, 0011_1011b
MOV CX, osmsgend - os_msg           ; calculate message size. 
MOV DL, 30
MOV DH, 0
PUSH CS
POP ES
MOV BP, os_msg
MOV AH, 13h
INT 10h
JMP wel

wel:
MOV BH, 00h
MOV BL, 07h
MOV AL, 1
MOV BH, 0
MOV BL, 0011_1011b 
MOV CX, welcome_end - welcome       ; calculate message size. 
MOV DL, 32
MOV DH, 2
PUSH CS
POP ES
MOV BP, welcome
MOV AH, 13h
INT 10h
JMP osmsgend
                         
welcome DB "Welcome !"
welcome_end:
                         
os_msg DB "BerlOS v0.0.1"
osmsgend:
JMP $

; Boot things
TIMES 510-($-$$) DB 0	            ; Fill the rest of the sector with zeros
DW 0xAA55		                    ; Boot signature

Thanks,
Nathan Paulino Campos

[gravaera]

I'm still trying to figure out what your question was. It seems that you're trying to ask where you can get some articles that discuss kernel theory. If you had simply gone to the wiki, you wouldn't even have had to search, since the home page has a bunch of links to kernel development concept articles.

Right there...on the home page of the wiki...there's this category in the little box thingies. The one called "OS Theory".

[Nathan]

The thing that i'm trying to say is: I need to start thinking in the development of a kernel to my OS?

[Brendan]

Hi,

I'm not too sure what you're asking...


I took a look at your code though. Some suggestions:

1) It's a bad idea to use code for padding (e.g. "NOP ; Pad out before disk description") because when you change anything you mess up the padding. A better idea is to use "align" or "times". At the start of the code I'd use "times 3-($-$$) nop" (just like you did at the end of the code).

2) The volume ID (called the "serial number" in some documentation) is used by DOS/Windows to detect when the floppy disk has been changed (mostly because the floppy hardware isn't very good at detecting disk changes). Basically if the volume ID/serial number for the current disk is the same as the volume ID/serial number in the OS's disk cache, then the OS can assume it's the same disk (even when it's not) and won't flush it's disk cache (which can lead to data corruption as a worst case). For this reason the volume ID/serial number should be generated in a way that reduces the chance of different floppy disks having the same volume ID/serial number. One way of doing this (for NASM) would be "VolumeID dd __TIME_NUM__ ^ __DATE_NUM__ ; Volume ID: any number" (which would be a different number every time you assemble it).

3) For "OEMLabel db "BERL OS" ; Disk label - 8 chars" the string only adds up to 7 characters (not , and "VolumeLabel db "BERL OS" ; Volume Label: any 11 chars" the string only adds up to 7 characters (not 11). It'd probably be a good idea to pad both of these with spaces so they're the right size (e.g. "BERL OS " and "BERL OS "). If these fields aren't the right size then the "FAT12" file system type will be at the wrong place and no OS will be able to figure out that the disk is using the FAT12 file system.

4) For assembly, it's easy to make a typing error (for example, typing "PUSA" instead of "PUSHA") where the assembler thinks it's a label (e.g. "PUSA:") and not a mistake (which means you don't get an error message, and your code crashes because there was no "PUSHA"). To avoid this problem I recommend turning on warnings about orphan labels (for example, for NASM you'd use "nasm -w+orphan-labels") and always use a colon after every label (e.g. "FileSystem: db "FAT12" ; File system type: don't change!" and not "FileSystem db "FAT12" ; File system type: don't change!").

5) Most (all?) assembly language programmers use several spaces or a tab before any instructions. This makes it a lot easier to see where labels are (which makes it easier to read and maintain the code). For an example (with 5 spaces before instructions):

Code: Select all

wel:
     MOV BH, 00h
     MOV BL, 07h
     MOV AL, 1
     MOV BH, 0
     MOV BL, 0011_1011b 
     MOV CX, welcome_end - welcome       ; calculate message size. 
     MOV DL, 32
     MOV DH, 2
     PUSH CS
     POP ES
     MOV BP, welcome
     MOV AH, 13h
     INT 10h
     JMP osmsgend

6) Sometimes you can reduce the size of your code (and improve performance) by doing a few things with one instruction. For example:

Code: Select all

wel:
     MOV AH, (13h << 8) | 1              ;ah = function number, al = "update cursor after writing" flag set
     MOV BX, (0 << 8) | 0011_1011b       ;bh = page number, bl = attribute
     MOV CX, welcome_end - welcome       ;calculate message size. 
     MOV DX, (2 << 8) | 32               ;dh = row, dl = column
     PUSH CS
     POP ES
     MOV BP, welcome
     INT 10h
     JMP osmsgend

There's also a few other things you could do to reduce the size of the code, like removing redundant instructions. For example, there's 2 places where you load values into BH and BL, don't use these values, then load different values into BH and BL (where the first 2 "MOV" instructions could be deleted); there's one place jump to the next address (e.g. "JMP wel") where the JMP could be deleted; and you could shift the final "JMP $" so that you can delete the "JMP osmsgend".

Also note that for a boot loader (where you've only got 512 bytes to use, and some of them are taken up by the BIOS Parameter Block, etc), you'll need every byte you can get your hands on before long...


Cheers,

Brendan

[Brendan]

Hi,

Ahh - sorry (you posted while I was writing my last post).

The thing that i'm trying to say is: I need to start thinking in the development of a kernel to my OS?

The next thing you'll need to do is read about different types of kernels, and then decide what sort of kernel you're going to write.

Once you've made that decision you'll have to start planning what comes next. For example, for a monolithic kernel the next step might be adding code to your boot loader to find the kernel and load it from disk into RAM. Alternatively, for something like a micro-kernel you'll probably need to load a lot more into RAM (e.g. a boot image that contains lots of files, including the micro-kernel, some device drivers, etc).

You'll also need to decide if you want a "second stage". The basic idea here is that it's almost impossible to squeeze everything into 512 bytes without making major sacrifices (e.g. like not having any good error messages in case things wrong, like read errors). Most people use the boot loader to get something larger into memory (the second stage) and then use this second stage to load everything else into RAM.

In addition, IMHO it's probably a good idea to write some sort of "boot state" specification for your OS, which describes exactly what the boot loader (and second stage) must do, and exactly what the next piece of code (e.g. the kernel) can expect. For an example, here's mine (it's a bit messy and a little complicated, but it should help to explain what I'm talking about). The idea is that your "boot state" specification guarantees compatibility between pieces of code used during boot; and you (or anyone else) can write lots of different boot loaders (e.g. one for floppy disks, one for CD-ROM, one for booting from network, etc) that all put the computer into the same state (so that the next piece of code doesn't need to care which boot loader was used).


Cheers,

Brendan