Hi to all,

No i don't want a two way communication between Prog1.c and Prog2.c. Prog1.c just sends the signal and it continues it's execution in parallel, without having to wait for Prog2.c to finish. Prog1.c kind of sends the signal and forgets about it.

One thing though..is it possible to send a signal from Prog1.c and not have Prog1.c waits for the return. Can we have a signal that does not return to the program that generated and sent it? I want to do sth like this: Prog1.c issues the signal and then continues with the remaining statements. Is this possible? How can I do that?

Any input will be very much appreciated..

Warm regards,
Visham

You want a communication (kill) from the kernel (Prog1) to a userland process (Prog2).

You want too the kernel (Prog1) to call a userland process (pidof) to retrieve a process ID.

You have to think carefully on how you want to achieve both of these tasks, as you are on your own when writing kernel code, no libraries, no (g)libc are available and no bugs are allowed ...

Absolutely correct..for the signal from kernel to Prog2.c, i'll use kill() in the kernel code and sigaction in Prog2.c to catch it.

For the retrieval of the pid of Prog2.c by the kernel program, i can use global variables to store the value of getpid() in Prog2.c and then access it from kernel code.

One question though..how come you have no libraries, no (g)libc are available when doing kernel coding? Then how are we supposed to write programs? I didn't know abt this issue and would be grateful if you could enlighten me on this. Also if you have good sources of info on this and kernel coding, do let me have them.

Warm regards,
Visham

Hmm, I already wrote a couple of times, but let me do it once again:

You are not going to call kill() from the kernel, because you have no access to libraries and system calls
Well, this is even harder, how will the kernel access these "global variables" ?
A global variable is global to all functions of a process, but not between processes, and even less between a userland process and the kernel.
Kind of chicken and egg problem, the kernel need to embed everything it needs and not rely on services provided by ... the kernel.
Programs and kernel code/modules are different beasts.
I already post a link to a site you seem to have overlooked.

Hi,

>You are not going to call kill() from the kernel, because you have no access to libraries and system calls

I intend to add a few lines of code to a function in iptables (kernel code). Do you mean to say that I will not be able to use the kill() function there? If no, what do you suggest me to do about what I want?

>Well, this is even harder, how will the kernel access these "global variables" ? A global variable is global to all functions of a process, but not between processes, and even less between a userland process and the kernel.

Some one told me that we can declare global variable in /etc/profiles. Variables defined there can be accessed from anywhere - both kernel space and userspace code. To read/ write to that variable, i will have to employ semaphores i believe.

>I already post a link to a site you seem to have overlooked.

No, i didn't overlook it..it's actually a website that i had used in the past but had forgotten about lately..thx for reminding me.

Warm regards,
Visham

J

Exactly. kill is a system call, and you can't use system calls from inside the kernel (Hmm, didn't I wrote that already ...).
Do it the way around, have a userland process communicating with the kernel. One way to do it would be using the procfs facility.
Actually, my best suggestion would be to discourage you to start such a project which seems unreasonably overcomplicated. Kernel programming is a job for skilled veterans.
The one who told you that is confusing very different variables and has no clue about what means kernel space. Environment variables set in /etc/profiles are anyway not at all shared between processes, and definitely outside kernel scope.

First of, many many thx for taking the time to explain all this to me..otherwise i would have been losing so much time on it.

One thing though..how does iptables kernelspace code iteract with iptables userspace code? Does it use the procfs facility?

And are there no instances in Linux where the kernel communicates with a userspace program (in terms of error messages, interrupts...)?

Warm regards,
Visham

It is normally the way around.
I don't think so, but it uses getsockopt() and setsockopt().
The kernel is a facilitator for userspace process communication. The scheduler is also responsible of the order and time slots each process will be granted the CPU. The kernel do send error messages to processes, but it can terminate them, dump cores, swap them out, but this can hardly be considered as communication. Of course error codes can be returned in reply to a system call, but the kernel is not the initiator of the dialogue.

How does the scheduler interrupt a running process and then schedule another? Does the scheduler sends a SIGINT?

Can we force the kernel to send sth to a process. If yes, can't we send sth to my userspace program so that when it receives it, it knows that it has to execute.

Regards,
Visham

It doesn't send a SIGINT, only processes send signals, the scheduler (in the case of preemptive scheduling) is just interrupting instantly the process, in a way absolutely transparent to the process which is unaware of it, and managing properly the context change to allow another process to take place.
You do not force the kernel to do something, but you can code part of of the kernel or modules that will do what you want, assuming you know enough of the kernel internals to do it, but this is poor design. Sending something to a process would imply that this process has code to receive and react to the message, which the kernel doesn't know. Logically, it is the process the one that should ask the kernel for information.

the command "top" without quotes gets the processes and proabably their pid too. You can push control + escape to get a thing like task manager.

Hi,

When i was saying that the kernelspace program has to send a signal to the userspace program, i didn't actually had in mind the use of signals or other system calls at first. Now, thx to you, I know it's not possible. I just wanted the kernelspace program to tell the userspace program to start its execution. This is the part I don't know how to do. This is where the problem lies.

I don't what and how we can send. If we manage to send anything, then we can make the userspace program catch it. I don't want a 2-way communication between these two programs. The kernelspace program just send "the thing" and then continues its execution. Both execute independently. No results to be returned to the kernelspace program. It's only 1-way communication. It's as if the kernelspace program schedules the userspace program to run.

What do you think?

To fakie_flip: I don't think 'top' will work in kernelspace. Thx anyways..

Warm regards,
Visham

You still view the kernel as an ordinary process, which it is not.

You can have the kernel sending something through a device driver (/proc for example).

If a process reads that piece of information, you have a communication from the kernel to a process.

Yes..we can try to do that..

Do you have idea abt wat we can send? Do have any example of how to do it?

Pls do let me have it.

Warm regards,
Visham