What a kernel consists of

[MeLkOr]

I was just wondering what a kernel program would consist of. Like what do you put in the program?
-MeLkOr

[Pype.Clicker]

short answer:
anything you'll need in order to provide the required services to end-programs

Now, as you can guess, it depends on what services you want to offer to these programs

The simplest kernel i can think of at least require user interaction (reporting keystrokes to the application and allowing stuff to be drawn on screen ... and eventually translating keystrokes into ASCII or stuff), programs execution (allocating memory, reading program from storage area -- even if it's just a disk image) and minimal API support (thus implying a way to call the system from the program, for instance to terminate the program or start a new one).

This being done, you can improve your kernel in a number of ways, providing for instance network services, more file systems supports, more system calls, more drivers, etc. but i prefer thinking of them as kernel extension modules rather than being really 'in' the kernel as the system can run without them ...

[Pype.Clicker]

for a more complete answer, see post #9 in this long-burried thread

[MeLkOr]

Does anyone possibily have sample kernel that was written in C? Is it possible to write a whole kernel in C or do you have to use another language?
-MeLkOr

[MeLkOr]

So would it be considdered a kernel if i had a little command line type thing that would perform operations if you typed certin commands? Even if it was still a windows based program?
-MeLkOr

[Tim]

Does anyone possibily have sample kernel that was written in C?

I learned from this one.

Is it possible to write a whole kernel in C or do you have to use another language?

Once again, C is fine! Most operating system kernels tend to be written in C (although you must use assembly language once or twice).

So would it be considdered a kernel if i had a little command line type thing that would perform operations if you typed certin commands? Even if it was still a windows based program?

Well, I guess it would fulfil certain definitions of 'kernel'. But that's not what this board -- and OS development in general -- is about. OS development is about running the whole machine and doing something useful with it, not reinventing CMD.EXE.

[BI lazy]

Art thou willing to return the silmarils, oh Dark Melkor? *gggg*

Feel invited to inspect the quicklinkz section for further information and consider buying a good book about the topic OS-Development - like Andrew Tanenbaum: OS Development and implementation II.

Ah, and don't you dare to forget the returning of the silmarils :p

[Pype.Clicker]

So would it be considdered a kernel if i had a little command line type thing that would perform operations if you typed certin commands? Even if it was still a windows based program?
-MeLkOr

What you described is more like the shell of the OS. Actually, the kernel is the dark magic that performs operations behind the shell.
The kernel is generic and not bound to a specific use. Therefore it has virtually no "main()" code: it just has services and interrupt handlers.

for instance the shell may be:

Code: Select all

#include <os.h>

main() {
    char buffer[LONG_ENOUGH];
    int errcode;
    while(fileReadLine(STDIN_FILE_HANDLE,buffer)) {
        if (strcpy(buffer,"exit")!=0) {
            if (fileExists("/bin",buffer)
               errcode=exec("/bin",buffer);
            else fileWriteLine(STDOUT_FILE_HANDLE,"invalid command. try 'help'");
           if (errcode) fileWriteLine(STDOUT_FILE_HANDLE,errmsg[errcode]);
           fileWriteLine(STDOUT_FILE_HANDLE,"$>");
        } else exit(0);
     }
}

Everytime you press a key, the kernel will invoke the keyboard driver to make it process the keyboard data. The keyboard driver will then use some of the kernel services to deliver the user program that currently has the keyboard focus (thus you'll need another OS service to select this).

Once the keyboard has received an "ENTER" keystroke, the kernel will know that the shell's "readLine" command has completed and will resume the user-level program execution.

The shell will then issue a 'fileExist' os call, which will make the OS retrieve the list of files in the directory "/bin" -- eventually using the File System and making calls to disk driver -- and reply to the user program by "true" or "false" ...

things go on when the user program invokes "exec" or "exit" system calls: once again, kernel functions are executed with user-provided args.

So you can see the kernel like a library which would have some special behaviours like:
- the fact it usually cannot be called like simple functions calls, but need an interrupt or trap mechanism
- the fact it executes at a different priviledge level than the caller and therefore needs to be paranoiac about given arguments (look at the "readLine", which has no idea of the buffer'size what if the buffer is too small ? this call is badly designed for the sole purpose of the example. never do this in a real OS
- the fact that it may receive concurrent calls from different programs.
- the fact that it has the ability of starting new programs, interrupt running programs, etc.

hope it helps.

[Schol-R-LEA]

Perhaps a more formal definition might be of use here:

[tt]Kernel
The conceptual core or heart of a system, providing the most basic infrastructure, upon which the rest of the system is built up from and is dependent upon for basic functionality.[/tt]

While it is most often applied to operating systems, the term is used in several other contexts as well; thus you may hear of a language kernel (the basic structure of a language without it's supporting libraries, also called the 'core language'), or a graphics kernel (a basic library of graphics primitives), among others.

Furthermore, not all OSes are based on kernel designs; MS-DOS, early versions of MacOS, and VM/CMS are examples of operating systems which have no kernel in the conventional sense. The kernel design first appeared in the mid-1960s with a system called Multics, and was inherited from it by Unix; the popularity and success of Unix, and the advantages of kernel-based designs, has led to most OS developers in the past twenty years to adopt the technique.

Among OS designers, there is endless debate as to what should and shouldn't be part of an OS kernel. It is generally agreed that it is important to keep the kernel as small as possible, to make it easier to understand and minimize the number of possible flaws. However, there is a great deal of controversy over just what constitutes a 'basic operation', and what it means for some thing to be 'a part of the kernel'. Designs may run from the MIT Exo-kernel, which is solely a hardware virtualizer (like VMWare) and has no system services at all, to the Windows XP kernel, which incorporates support for the GUI and networking into the kernel itself.

What most (but not all) OS designers agree upon as being necessary for the kernel are:

• Process management (creating, detroying and scheduling tasks);
• Memory management (keeping track of what memory is in use, and handilng requests for additional memory);
• Interrupt and exception handling (usually part of process management);
• Error handling (e.g., recovering from application crashes, killing runaway processes - again, usually part of process management);
• Inter-process communication (signals, semaphores, locks, messages);
• System security (preventing malicious or runaway programs from corrupting other processes - generally part of memory management);
• System API (i.e., handling system calls by user processes);

In addition, it may have some minimal hardware support, enough at least to allow the system to load in more a complete set of drivers, though many designers now see this as being the job of the boot loader (which is a completely separate program from the kernel in most modern systems). Most systems also place the file system (or a logical file system, if it supports more than one actual file system) into the kernel, as well.

Obviously, while the kernel is conceptually the most important part of an operating system, it is not the only part, and in most systems it is completely hidden from the user. The things most users (or even most programmers) think of as the system - the user interface, the default directory structure, the utilities and basic application software - are usually not part of the OS at all. For example, most of the shells and basic utilities used in Linux (e.g., [tt]bash(1)[/tt], [tt]cat(1)[/tt], [tt]less(1)[/tt], [tt]man(1)[/tt], [tt]gcc(1)[/tt]) are from the GNU Tool Kit, and predate Linus' original kernel; the exact same tools are used in FreeBSD and it's cousins, and even have been ported to Windows. The kernel may be the fundamental part of an OS, but when it works properly, it works silently.