OSDev.org

Hi guys (again...I should find something better to start a topic with...)

So...anyway I am just curious about this question. When we code our OS (or at least mine as of now), it is still just a kernel (after all I have to specify that it is a kernel when I run it from qemu). So, what exactly makes a OS kernel become a proper OS (like the fact that applications are loaded or something?)? Also how do you do it? (is it the GRUB module or do I load it from my kernel?)

Anyway, I think I should add an invisible ninja to protect myself from all evil or threats to remove my OSDeving licence due to my noobness (which I might be) or the Blue Screen of Death (but even evil shudders when it hears of the Blue Screen of Death) *puts invisible ninja*

hometue wrote:Hi guys

Hi Damien!

hometue wrote: So...anyway I am just curious about this question. When we code our OS (or at least mine as of now), it is still just a kernel (after all I have to specify that it is a kernel when I run it from qemu). So, what exactly makes a OS kernel become a proper OS (like the fact that applications are loaded or something?)? Also how do you do it? (is it the GRUB module or do I load it from my kernel?)

I would say that the kernel is a subset of an OS.

An OS (to me) is a set of libraries and other infrastructure (shell, ect.), which allows me to built new programs and/or get specific tasks done (like posting an answer on osdev).

The kernel is a subset, in that it's the module which allows for bootstrapping of these libraries and infrastructure tools.

My definition of an OS is indeed fuzzy, but the main point here is that, the kernel on it's own, is not directly usable, without the OS layer on top. However usually I expect more than a shell of my OS, but again this depends on the usage context.

Linus Torvalds wrote:Sadly, a kernel by itself gets you nowhere

Kernel without applications is entirely useless, unless you manage to get the whole userspace inside it, which is a bad idea.
The applications aren't a GRUB Module, if I understand you correctly you mean programs, that use kernel services and are NOT a part of the kernel. What you do is that you load the file (first you need a file system like FAT) into RAM, and simply jump to that memory location, This method is only for simple single tasking systems, if you plan to use a file format you may have to parse it, the file may contain some important things like what dependencies are required, what minimum CPU the program requires, what kernel version it runs on, who does the program belong to, etc. You can look up on existing formats like DOS-MZ, Windows PE, ELF etc.
If you don't want to parse the file but simply load it and run, you can have your application as a binary file.
As for the kernel services you can use interrupts like how DOS used INT 21h as an example.

How much you put into the kernel, and how much you have running as background services, is up to you. Some things have to go into the kernel, such as memory management and the dispatcher. Probably a hard disk driver, a driver for the default file system, and possibly equivalent drivers for an optical drive (at least if you want the option of booting from a CD) would need to go in as well.

Other drivers you might want to run as privileged processes. Also running as separate services might be routines to do some systems housekeeping - such as freeing up pages in memory, which have not been accessed for some time. Something else which might reside outside of the kernel is the graphics server. Then you can implement that after you have got at least a command line interface running.

Does even matter? It's names that try to explain real things that are so complex that kernel and operating system are too simple terms to truly convey any meaning except the broad category of what the object is.

mathematician wrote: a driver for the default file system

I think the Windows NT NTFS driver is loaded by NTLDR/BOOTMGR at boot-time, which is in NTFS.SYS, (is this correct?)
Infact the Windows NT Kernel (NTOSKRNL.EXE, NTKOSKRNLPA (PAE)) only forms a small part of the Windows NT Operating System, Everything is a different module, even the Hardware Abstraction layer is a different file (HAL.DLL), or the Windows Native API (NTDLL.DLL) or the Application API (KERNEL32.DLL)
You could as well make your bootloader load the drivers for you.

sid123 wrote:

mathematician wrote: a driver for the default file system

I think the Windows NT NTFS driver is loaded by NTLDR/BOOTMGR at boot-time, which is in NTFS.SYS, (is this correct?)
Infact the Windows NT Kernel (NTOSKRNL.EXE, NTKOSKRNLPA (PAE)) only forms a small part of the Windows NT Operating System, Everything is a different module, even the Hardware Abstraction layer is a different file (HAL.DLL), or the Windows Native API (NTDLL.DLL) or the Application API (KERNEL32.DLL)
You could as well make your bootloader load the drivers for you.

Whatever Microsoft's reason for doing it that way, there does not seem to be much point in having a separate boot time driver to load the main system driver. If the kernel's hard disk or file system driver crashes, you are stymied anyway - because you would need the driver to reload the driver.

Also, it is useful to have a memory manager running before anything except the kernel is loaded.

mathematician wrote:How much you put into the kernel, and how much you have running as background services, is up to you. Some things have to go into the kernel, such as memory management and the dispatcher. Probably a hard disk driver, a driver for the default file system, and possibly equivalent drivers for an optical drive (at least if you want the option of booting from a CD) would need to go in as well.

Certainly no proper microkernel has a disk or filesystem driver built in. Loading these drivers from the disk is the job of your bootloader, so that the kernel can take an in-memory image of the executable and create a process for them without having to access the disk by itself.

Multiboot supports this as so-called modules, so you'll be able to go this route with GRUB, syslinux, qemu -kernel, etc.

I use a third alternative. I don't link a mega-kernel as Linux does with a basic drivers, and I also don't load drivers from file, rather have one single binary which contains the relevant drivers only (which is configured automatically or with a tool). I can do this because of how the syscall-interface is built which allows run-time linking of services without separate files. When I use mulitboot, I pass the whole OS-image as a module, and then boot a "stub" which creates the proper RDOS environment.

Ah, so you found Good job.

rdos wrote:I don't link a mega-kernel as Linux does with a basic drivers

Yup, that's how most default setups of Linux distributions worked some ten, fifteen years ago. These days the typical kernels are rather minimal in their built-in driver support and the required drivers (including disk and file system) are loaded from an initramfs, which is a single file loaded by the bootloader. Not sure how many drivers typical initramfses contain today, but at least some distros used to have only the required drivers for the specific machine there. I've had trouble before when moving a disk to different hardware. Having all drivers available wasn't such a bad idea, after all...

Kevin wrote:Having all drivers available wasn't such a bad idea, after all...

Having the ability to easily configure it, and avoid lengthly installs on identical machines is a much better idea.

The only problem is that you can only configure anything when you have a running system.

Kevin wrote:The only problem is that you can only configure anything when you have a running system.

Not at all. I configure my systems with a bootable USB-stick. The stick will transfer the OS binary (including all drivers) to the disc of the target. The OS binary can be created on Windows. Thus, I don't need a lengthly OS installation procedure that does everything from scratch when I already know which binary to use.

The problem is only to create the first bootable USB-stick. Once you have one, you can create another from within the OS itself.

In that case your USB stick contains the running system.

I'm not saying that having only the specific drivers around means that after putting the disk into a different machine, the setup is broken beyond repair. It's just inconvenient compared to the state when things just kept working.