IPC between tasks in kernel

I can think of several different methods such as: - sockets - a pair of pipes (named or otherwise) - pseudo terminals (pty's) - shared memory w/ semaphores - MPI / PVM / CORBA or another message passing system (usually built on top of one of the mechanisms already listed)

and so on. Just analyze their capabilities and pick one.

--Mark

The OP was asking about the kernel, not some userland IPC methods... And there's no need for IPC inside the kernel since everything in the kernel has access to all kernel memory.

Regards, Jens

Are you sure? He is asking for IPC between tasks, generally a user land construct. Note also that much of what I described in my answer IS implemented in the Linux kernel - see man 2 socket for an example. I suggested user land examples as the last item since they may be easier to use / or more portable than the direct system call interfaces.

Eh? I do not see this comment being helpful at all to the OP nor relevant to my comment. Please explain your rationale.

--Mark

I think so because of the subject line "IPC between tasks in kernel" and the "Inside the Linux kernel" part in the question - but I can, of course, be wrong;-) The other possibility I would see is that the OP wants to know how support for things like shared memory/message queues etc. is implemented within the kernel. It would be definitely good if he/she would explain more clearly what's that all about...

He is asking for IPC between tasks, generally a user land

I just meant that (according to my interpretation of the question) that there'ss no need for some "IPC" within the kernel since within the kernel different "tasks" don't have separate address spaces. So "TaskA" could set up e.g. some (non-static) structure and that way "TaskB" could read what "TaskA" put in there and write into it whatever it thinks necessary.

Regards, Jens

Hi Guys,

My question was pertaining to tasks *inside* the kernel. What I really want to do is this.

I have some callbacks which get called in the kernel. I want to send a cook up a message and send it to the other task(B). Task B just keeps waiting for these messages and handles the message. Is it possible to do this?

Thanks, Vividh

snipped-for-privacy@physik.fu-berl> >

And what do you mean by "tasks"? There are kernel threads; well, there are threads - some of them started from within the kernel.

Yes. What's the problem? Put your message someplace and signal when it's ready to be read. Have the other thread sleep on that signal. Or use a semaphore.

Peter

Yeah Only Threads lies inside Kernel.Use kmalloc and allocate buffer ,store messages in that buffer.Use an Interrupt mechanism to send the message to another process when it is ready.In Interrupt handler read from the allocated buffer. For advanced operation u can use some buffer management .. I think this solves ur problem....

Regards

Why do you want to do that? Why do you want to communicate with a different thread, when you can just do it yourself?

First - you don't have "tasks" in the kernel. You can have threads, created by the kernel, that basically run within the kernel address space.

What is the context that this callback function gets called [e.g., interrupt, with or without locks held, allowed to sleep, ...]? Your solution will vary based on the context of the implementation.

Certainly.

Look at the interfaces that implement one of [from a recent 2.6 kernel] ... - [ksoftirqd/#] - [pdflush] - [aio/#] - [kjournald] There are about two dozen of these kernel threads on my 2 CPU system. Review how hey work / choose the method that matches your situation the closest / implement the same interface. A quick grep... # grep -ir pdflush /usr/src/linux-2.6.10/ gives a couple hundred hits including comments on a pool of worker threads, structures for passing work to those threads, a list of operations to perform, protection by locks, and so on. That certainly covers all the bases but may be "too heavy" for your application.

--Mark

Hi Mark,

Thanks for the po> VSS wrote:

The Kernel Threads sometimes are called "Taskslets" :).

I suppose with the kernel threads there are big differences between Kernel v2.4.x and 2.6.x.

In a (German) article on 2.6 Kernel Threads (German Linux Magazine

Different types of "Kernel Threads": (1) running an a process context: "Kernel Threads", "Workqueues", "Event-Workqueues". (2) running in an Interrupt Context: "SoftIRQs", "Tasklets", "Timers".

Some more pointers: There are priorities. Race conditions need to be looked at. "add_timer()" will call a kernel function after a predefined time. "ps auxw" shows kernel Threads. "kernel_thread()" creates a kernel thread (similar to "clone()" ). "wait_event_interruptible_timeout()" makes a kernel thread sleep by a "waitqueue". "workqueues" might be better than "waitqueues" created by "queue_delayed_work()" .

-Michael

Please have a look at workqueues/taskqueues/waitqueues which will allow u to manage synchronization problems and everything u could set up a commom buffer between the the kernel threads/tasklets/tasks and use waitquesues to signal availability of data BTW semaphore are also available in the kernel which u can use for syncing with shared buffers as mentioned earlier u dont need to explicitly share buffers or data as all global data is visible to all tasks in the kernel

I don't think a tasklet is the same as a kernel thread. But I think in recent kernels tasklets are implemented using kernel threads. Somebody knowing tasklets a bit better may fill in the blanks.

I don't know about any fundemental change to the way kernel threads works in 2.4 and 2.6. Of course kernel threads also get advantages from the improved scheduler, and a lot more kernel threads are used now.

Right. Tasklets seem to be more like ISRs for virtual interrupts.

Good to know. Thanks.

-Michael