Communication

[Lucus16]

We need to decide upon how we do this.

1. Kernel->Kernel communication is simple, we do it by direct JSRs. I don't think there is any need for a different system.
2. Process->Kernel communication can be done by either using JSR or INT. Using JSR has the advantage of being quicker, while INT has the advantage of not needing special addresses to store function pointers. Right now, JSR is assumed, I believe, but we should consider whether it is really the best..
3. Kernel->Process communication is not really documented yet, as far as I know. I imagine this being done by using signals. Signals are 1 word long. This is basically simulated interrupts. This also means we probably want to be able to queue signals, just like interrupts can be queued. The problem with this is, if we have a max of 16 processes at a time, and a queue of only 16 signals, and we need to store only the signal word and the sender, we still end up with needing a full memory page to store that. And we likely want more than 16 procs at a time.
4. Process->Process communication would then be possible using the same system, sending signals from one process to another. Messages could be communicated by saying all signal numbers above 0x1000 for example, are simply pointers to messages.

So, opinions on all of this please, how are we going to implement this. I need to know this soon to be able to make a proper dynamic interrupt handler.

[M52]

I THINK I understand the issues you list here but I want to make sure. Kernel -> Kernel is easy indeed, I understand that bit.

Process -> Kernel...I can follow that too, a process might want to access kernel functions or buffers at times (easiest example: reading the keyboard through the kernel provided methods).

Kernel -> Process. Would the kernel need to talk to a process? I am not sure about that...more so because we can not know in advance what kind of process will be ran. The kernel is entirely agnostic to what a process is doing...

Having said that, the only K->P communication I can think of is that the kernel requests information from the process (meaning that every process should have a handler by default which returns the requested information...and technically, this would be K->P->K communication, sort of a handshake. So that the kernel can verfiy that the process is legal).

Anyway...I am not sure WHEN K->P communication would be needed..

As for P->P communication, I talked with dilbertfan about that a while back. I think the idea has always been to use messages/signal in a specially allocated piece of memory (part of the header/structure of a process or program).. I am not sure how "saying all signal numbers above 0x1000 for example, are simply pointers to messages." would work.

It's probably just me who has a hard time with understanding how each of these elements would work, however, the advantage of me asking all these questions is that we can really make it extremely clear and easy to use. Not only to future users but also for ourselves.

[Lucus16]

Well, because I had a lot to consider, I may not have been very precise about describing what I meant. About signals, my idea was to let any signal of 0x1000 or above be a pointer to a message, so that when a process receives a signal above 0x1000, it simply looks at [signal] and that would be the start of a message. So the sender stores the message in his own process space, then sends a signal that holds the location of the first word of the message. How the messages are implemented is up to the processes, of course, whether they prefer fixed-length, null-terminated or otherwise. This is useful because the kernel doesn't need to allocate space for all messages that might ever need to be queued.

K->P comms example: Telling a process it should shut down. Telling a process it's filesystem request has been finished. Telling a process a timer elapsed. Etcetera...

[jrcrittenden]

Kernel to Process would be something like the following in a POSIX (*nix environment).
SIGKILL, Where the kernel tells a process to terminate, without questions, immediately.
SIGTERM, Where the kernel requests a process to terminate normally.
SIGSEGV, Notifying a process that it has segfaulted.
SIGQUIT, tells process to immediately commit coredump and exit.

Couple decent references:
http://en.wikipedia.org/wiki/C_signal_handling
http://en.wikipedia.org/wiki/Unix_signal

[viccuad]

My likings:

K->K : JSRs.

K->P I'm in for POSIX signals too. but as I have never thought about a CPU like this, without kernel mode in the CPU, and I haven't thought about problems derived from this. basically,is that the programs go rogue? and just ignore the signals?.
Also, how are the programs going to be created? I vote for an init process (parent of all the processes), and the fork (to create another process that equals the father) and exec (executes code) calls.

P->P I like sending signals above 0x1000, like software interrupts. and maybe is the only easy way to do it (we cannot use a call gate or a special system call instruction, we don't hw for that). I would add to this a memory-based queue, so we don't disrupt the "real time" or preemtive time in the kernel (preemtive = we allow temporal interruption or a funning process to run a higer priority process). after all, the system is going to be used for piloting and lifesustaining programs.

[Lucus16]

SIGTERM and SIGQUIT would be useful to implement. SIGKILL is useless however, it's much easier to simply make a kernel function that kills a process.

As for FORK, that's not a good idea either, copying the entire process, just to replace it with another core almost immediately seems rather redundant. I believe someone also said that a lot of the advantages of forking were in security issues, something we can't concern ourselves much with. So I think it's a better idea to simply make a function that loads a new process into memory from a file you specify.

As for the signal queue, I have a signal queue implemented right now that can store up to 16 signals. Right now, when a queue overflows, the last signal is changed into a missed_some_signals signal. I have been considering changing that to make the relevant process run immediately. That would make sure no signals are missed and it shouldn't happen very often because there is still a buffer of 16 signals.

[viccuad]

for FORK I would use a "forkexec" call, that makes what a fork & exec would do, but not copying and replacing, just load the new process into memory as you said.

we would need the "forkexec" call to return something: I as a programmer want to know when I'm in the child process or the father process after "forkexec-ing" so i can make proper decisions inside my code. like, you know:

program foo

returnedValue = forkexec()  //we create the child here! the child is another program foo, so it has the same code. 
                                                      //it starts running after the call to forkexec, and the value of returnedValue is == 0.
                                                      //the father also continues running, but with returnedValue == ID of child process

if (returnedValue == 0) then
     //I'm in the child
     this is child's code

else if (returnedValue < 0) then
     // forkexec returned an error, the error is different with the number returned: -1, -2 , -3 ..

else 
    //value returned is the process ID of the child process, and I'm in the parent process.
    // I can store that ID or use it or whatever
        this is parent's code!


endprogram foo

For the SIGNAL queue, I get nervous with only 16 signals. I think they are quite low. I would love to have that velocity for signal # < 16, but I would try yo expand it on running time when number of signals are > 16.

[Lucus16]

I'm not entirely sure what you mean, but if you do a forkexec that replaces the core of the child immediately, the code checking for the returnedValue would have been replaced before it could be ran, wouldn't it?

As for the signal queue, I'd love to do more, but having just 16 processes and 16 signals per process and then 2 words per signal so signal senders can also be stored, already uses a full memory page, and any more and the kernel would just become too big I'd imagine. Signal senders need to be stored because otherwise, a process can't reply to a signal sent by another process.

[viccuad]

the fork makes "spawn" another process, that is a copy. the exec just gets all the code of the child process to be changed from other code in a file, for example.

this maybe can throw some light on this:
http://www.bottomupcs.com/fork_and_exec.html