OSDev.org

I have some doubts about what to do once one has certain support for filesystems, keyboard/mouse and basic screen.

The kernel functionality is sitting there waiting for something to trigger it in an ordered form, such as requesting read/write files, display to screen, etc., but how exactly is that triggered once all the kernel components get initialized?

Assuming one has basic support for multitasking, should a new process be called, some privileged/special application to figure out the meaning of the detected information of devices and fundamental software and present it to the rest of the system in a C-library-like fashion, as well as presenting the disk units, etc.?

Should this special application process some initialization script to configure paths, services and finally the user interface, be it either console or graphical?

If there isn't any better way (how you do it!?) should this executable binary be in a static location so that the kernel loads it, given that it actually (presumably) goes beyond the stage of boot loaders and the kernel core, such as a separate partition like that of GRUB?

but how exactly is that triggered once all the kernel components get initialized?

Software Interrupts

~ wrote:The kernel functionality is sitting there waiting for something to trigger it in an ordered form, such as requesting read/write files, display to screen, etc., but how exactly is that triggered once all the kernel components get initialized?

Presumably, once you have a functioning kernel, and also an initialisation routine to set up protected mode, configure the device drivers, load the GDT and IDT, etc, the final thing the initialisation routine needs to do is load and run the ordinary executable program which is to act as the user interface. Like all other user space programs, it will make calls to the kernel to get things done. Beyond being the first executable loaded there is nothing special about it; some operating systems even allow you to substitute your own user interface program in place of the one which comes as standard.

Well you could just do it like most unices and mount a partition specified on the kernel command line as the 'root' and then (given that you have filesystem support in kernel) load the /sbin/init executable from that location.

Personally, I'm designing a microkernel, where ide and filesystem drivers aren't in the kernel. They are provided as modules by grub, which also provides a file detailing initial configuration (e.g. which filesystems to mount and which init process to call) in xml format. I find this gives me more flexibility than a kernel command line.

From the sound of your post you don't have a virtual file system-type layer yet. This is where you generally make the device->C library space mapping. My plan for my system is to go slightly beyond a virtual file system and design what I like to call a virtual information system, where I mount much more than filesystems, but also things like, for example, the user account list, http sites, ldap directories and subversion repositories. Basically I plan to be able to mount anything where the driver exposes a standard ICollection interface.

Regards,
John.

Nice, I'm also designing microkernel and I have it done like this:

Three step boot/loader is loading kernel/GDT files and detects memory.
Then when he initiates Memory Manager with page granularity it loads INIT.DAT file which consist data about which apps to load. Loader loads them and then passes control to kernel. Kernel initiates all IDT like structures and creates paging and other sys structs for apps from list. Then it dispatches first app. THis apps are treaten as Root/System apps on User CPL3 level.
This apps are basic hosts needed for user to work, like FDD driver FAT12, VFS, keyboard, screen, login, console.