From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751054Ab1JGEAa (ORCPT ); Fri, 7 Oct 2011 00:00:30 -0400 Received: from mail.lang.hm ([64.81.33.126]:51226 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750698Ab1JGEA3 (ORCPT ); Fri, 7 Oct 2011 00:00:29 -0400 Date: Thu, 6 Oct 2011 21:00:13 -0700 (PDT) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: Cyclonus J cc: Andi Kleen , linux-kernel@vger.kernel.org Subject: Re: intercommunications between Linux kernel modules In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 6 Oct 2011, Cyclonus J wrote: > On Thu, Oct 6, 2011 at 7:04 PM, Andi Kleen wrote: >> Cyclonus J writes: >> >>> I am looking for a way to do an IPC-like communications between two >>> linux kernel modules, such as mqueue or shared memory. After searching >>> for a while, I can't find such information available inside existing >>> linux kernel or online. >>> >>> So, my question is if this is something discussed before here and gets >>> rejected or still might be accepted in the mainstream kernel tree? >> >> All kernel memory is shared in Linux, so the concept doesn't make sense. >> >> If you want to send messages or communicate inside the kernel there are >> lots of different facilities available. > > Andi, > > That would be great! Could you point me to some facilities that can do > this message passing between kernels? what you are missing is that there aren't two different kernels. it's one big process. think multi-threaded programming instead of inter-process communication. You don't even have well defined threads to work with so you can't say "I'm in thread 1 and need to communicate with thread 2", you need to think "I'm in this routine and I need to set a message in a way that another routine will read it", this can be as simple as just setting a variable (although you do need to make it the equivalent of 'thread safe' through appropriate locking or lock-free protection) David Lang