OSDev.org

..

this sounds like a good' ol boot sequence. However there's a few points i have to disagree with.

1. I would not recommend the use of a 'table' for the tasks. The main reason is that i don't see why your system should be limited to N tasks (whatever N is. If N is accepted, why should N+1 be rejected ?) I would instead suggest a dynamic structure like a tree, a list or whatever.

2. I would not put the UI task straight in the kernel. The main reason for it is that the UI is already a Big Thing (tm) per se and that i don't think it's wise to join two Big Thingz that have little interaction.
If you decide to have the UI at kernel level (this is, creating windows and controlling widget will be like creating a new process or sending a message over the network), you should at least ask yourself the question "what if i want to add a new type of widget ?" if the answer contains "recompile the kernel and reboot", your design needs adjustments.

3. It also looks like your kernel needs to do something more in order to continue the OS boot procedure, like running the "init" program, or whatever. The kernel itself is initialized. Fine. But what about the rest ? what about starting the printer daemon, establishing a connection with the ISP etc.
I'm not saying the 'kernel' needs to handle this, but it should at least be able to call a user-level program that will do it.

I do agree with pype: No user interface things in kernel initialization.

You might have a thread do some things for you - like starting up the memory management process.

Hmm ... and please initialize process management stuff as soon as possible: you'll need it. *gg*

Since the user interface is a ... subsystem of its own which makes use of the kernel, it is not a *wise thing (tm)* to put it into the kernel. Leave it as an extra process with it's own adress space - it has to talk to the kernel via system call (send/receive is all you ever need). I f. ex. use a classic store and forward mechanism for my message routing.

stay safe ...

@pype: for the rest of initialization, away from loading basic drivers like keyboard/video/system/pager ... which are the bare minimum to get it running, I too would have a kind of init process fork off the rest of drivers and services.

Fully knowing that people will probably throw stones at me ("one of the large sharp ones, and a bag of pebbles...")... your description of the early bootup is very close to what the Multiboot Specification specifies (A20, protected mode, memory map from BIOS). You might want to check it out, unless you actually want to spend time implementing Another Bootloader (tm).

@Solar: Nay, I won't throw stones and peebles at you .

Althou' the lust is biig, I don't want to nutrify a latent hankering to kick off Yet Another Bootloader Argument (tm). But (forgimme) I consider it a wise thing to try out and do it: to get that damned thing started. It bears some learning stuff, and I thing it belongs there: os coding, early steps: enabling a20, building temporary gdt, setting up temporary stack et cettara ... til enabling protected mode. Later on, our delinquent lustfully tinkering with a bootloader might ofcours switch mind and take grub or else...

stay safe.

..

yep, UI started by the init program sounds more natural.

I don't see anything wrong with doing research on operating systems that implement the user interface inside the kernel. I don't think that operating systems that don't implement their user interfaces inside the kernel have proven their superiority over those that do any more than microkernels have proven their superiority over monolithic kernels. If you feel that the user interface belongs inside the kernel, put it there.

That being said, I'll probably put my UI in userland.

kaos wrote: I don't see anything wrong with doing research on operating systems that implement the user interface inside the kernel.

The less you put at kernel level, the more stable your system can be. Also, it wouldn't be wise (imho) to have the UI strongly coupled with the rest of the system, because the UI is prone to change much more than other things.

So i think that if the UI is implemented at kernel level, it should at least come as a module, not as a part of the "one big chunk" that is loaded at system startup, or have most of its features (like font renderers, image decoders, widget code, etc) as plugins.

Pype.Clicker wrote: The less you put at kernel level, the more stable your system can be.

I don't quite agree. I would say that the system is more likely to be stable if user interface is in the kernel. However, I believe that the system would have better performance.

I tend to agree that the user interface doesn't belong in the kernel. I do think, though, that there is nothing wrong with researching kernels that implement a user interface.

Can you please tell me one reason besides performance that would justify putting a user interface program into the kernel?

I do not think, that it is the kernel's task to provide user interface. The kernel has to provide Interrupt handling and Message Passing/Routing from one task to the other one. All the other things are external modules to be loaded and initialized in form of tasks/drivers/processes. The kernel and the drivers/services provide the things *every program* needs: ipc, memory management, device access, some display services (gui handling remains at user/service level), and so forth. The Userprograms (to which I consider the User iNterface to belong to) make use of the services, the drivers and services offer to them. The kernel just passes messages and switches tasks at need. Hm. that is how I do it at least. Don't know what happens in a monolithic kernel, but I think, it is similar.

Stay safe

imvho, people that think about coding UI inside of the kernel
a. either never coded a UI and underestimate the difficulty of coding one
b. or never coded a kernel and underestimate the difficulty of debugging something at kernel level

It seems to me that there is a simple argument against placing the UI in the kernel: a GUI, by it's nature, is very complex, and it's complexity has the result of making it brittle. GUI crashes are common in most systems that use GUIs. A user space GUI which crashes can be shut down and restarted by the kernel; whereas a kernel space GUI may well take the kernel down with it. This is, of course, one the classic arguments in favor ofl microkernels, and usually is applied to drivers as well.

A counter argument to this would be that a GUI (or driver) in user space would be vulnerable to user-level errors and exploits.

The best, though hardly the simplest, solution to this is to use a multi-layered security approach. For example, on the x86, there is hardware support for four control rings, which could be used to separate different levels of software: CR0 used exclusively for the kernel; CR1 used for low-level drivers; CR2 for the file system, shell/GUI, debuggers, and other system services such as timer daemons, and HTTP servers; and CR3 being solely for application software. While it would be a pain to code, and require quite a bit of overhead, it would allow for a fairly secure and stable system. It is why the x86 CPU has four security rings instead of two, after all.

Pype.Clicker wrote: imvho, people that think about coding UI inside of the kernel
a. either never coded a UI and underestimate the difficulty of coding one
b. or never coded a kernel and underestimate the difficulty of debugging something at kernel level

I've coded a kernel, or at least large sections of one (kmalloc(), multitasking, coff executable loading, multiple address spaces, etc). I've coded various sorts of UIs.

Reasons that you might want to put the UI in the kernel include performance, smaller memory footprint, simplicity of coding, tighter control over UI policies, etc.

Reasons that you might not want to put the UI in the kernel include modularity and stability.

For most of the kernels with which we are dealing, the UI belongs in userland. I hypothesize, however, that there are instances where it makes sense to put the UI in the kernel. Writing your own kernel should not be a reimplementation of POSIX in every case. If someone feels that the user interface belongs in the kernel is his OS, I am not going to try to talk him out of it.