linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* new IPC mechanism ideas
@ 2001-07-11  1:49 Rajeev Bector
  2001-07-11  3:25 ` H. Peter Anvin
  0 siblings, 1 reply; 9+ messages in thread
From: Rajeev Bector @ 2001-07-11  1:49 UTC (permalink / raw)
  To: linux-kernel

We are planning to develop a new
IPC mechanism based on shared
memory. The memory is allocated by
a device driver in the kernel
and mapped to various processes
read only. Processes talk to the
driver to write to the memory
but they can directly read the
memory (so its a 1-copy IPC
mechanism). 

We also want to make this IPC
mechanism persistent across
application restarts. So that
if an application crashes, when
it comes back up, it can remap
to its old queues and get its
messages. 

Does anyone have experiences building
such a mechanism ? Any pointers to
reading material would be really
appreciated ? 

Please cc replies to rajeev_bector@yahoo.com

Thanks !

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: new IPC mechanism ideas
  2001-07-11  1:49 new IPC mechanism ideas Rajeev Bector
@ 2001-07-11  3:25 ` H. Peter Anvin
  0 siblings, 0 replies; 9+ messages in thread
From: H. Peter Anvin @ 2001-07-11  3:25 UTC (permalink / raw)
  To: linux-kernel

Followup to:  <20010711014918.76554.qmail@web14404.mail.yahoo.com>
By author:    Rajeev Bector <rajeev_bector@yahoo.com>
In newsgroup: linux.dev.kernel
> 
> We are planning to develop a new IPC mechanism based on shared
> memory. The memory is allocated by a device driver in the kernel and
> mapped to various processes read only. Processes talk to the driver
> to write to the memory but they can directly read the memory (so its
> a 1-copy IPC mechanism).
> 
> We also want to make this IPC mechanism persistent across
> application restarts. So that if an application crashes, when it
> comes back up, it can remap to its old queues and get its messages.
> 
> Does anyone have experiences building such a mechanism ? Any
> pointers to reading material would be really appreciated ?
> 

Why not just use mmap() on a file?  That way you can even make it
zero-copy.  Otherwise, mmap() readonly in all but one process ("the
driver").

Nothing needed in the kernel that isn't already there...

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: new IPC mechanism ideas
  2001-07-12  1:02       ` Rajeev Bector
@ 2001-07-12  1:07         ` H. Peter Anvin
  0 siblings, 0 replies; 9+ messages in thread
From: H. Peter Anvin @ 2001-07-12  1:07 UTC (permalink / raw)
  To: Rajeev Bector; +Cc: linux-kernel, hpa

Rajeev Bector wrote:
> 
> The point is that you can do IPC using
> this scheme which is
> 1) protected (as compared to a shared
>    memory (shm) scheme in which any process
>    can write anywhere and corrupt
>    everything)
> 
> 2) involves only 1 copy.
> 

You can still do it in user space, by having individual r/w shm mappings
to the controlling process, and ro mappings to the other processes; it's
still only one copy.

Introducing new forms of IPC adds to the complexity of the programming
model which is already too complex.  It therefore requires substandial
justification (unless you're doing it as a homework project in which case
you shouldn't be posting here), including presenting real-world
applications which cannot be properly served by current forms of IPC.

	-hpa

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: new IPC mechanism ideas
  2001-07-12  0:57     ` H. Peter Anvin
  2001-07-12  1:00       ` Alexander Viro
@ 2001-07-12  1:02       ` Rajeev Bector
  2001-07-12  1:07         ` H. Peter Anvin
  1 sibling, 1 reply; 9+ messages in thread
From: Rajeev Bector @ 2001-07-12  1:02 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel, hpa

The point is that you can do IPC using
this scheme which is
1) protected (as compared to a shared
   memory (shm) scheme in which any process
   can write anywhere and corrupt
   everything)

2) involves only 1 copy.

Thanks,
Rajeev

--- "H. Peter Anvin" <hpa@transmeta.com> wrote:
> Rajeev Bector wrote:
> > 
> > If your driver is in the kernel,
> > then you dont need that. All processes
> > use system-calls (or ioctls) to send
> > messages and when they do recv(),
> > they get a pointer to a location
> > (where they are mapped to via mmap)
> > and they can read directly. In this
> > scheme, you dont need any traditional
> > UNIX IPC mechanism to work.
> > 
> 
> And the point of this is?
> 
> 	-hpa
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: new IPC mechanism ideas
  2001-07-12  0:57     ` H. Peter Anvin
@ 2001-07-12  1:00       ` Alexander Viro
  2001-07-12  1:02       ` Rajeev Bector
  1 sibling, 0 replies; 9+ messages in thread
From: Alexander Viro @ 2001-07-12  1:00 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Rajeev Bector, linux-kernel, hpa



On Wed, 11 Jul 2001, H. Peter Anvin wrote:

> Rajeev Bector wrote:
[snip]
> > and they can read directly. In this
> > scheme, you dont need any traditional
> > UNIX IPC mechanism to work.
> 
> And the point of this is?

NIH


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: new IPC mechanism ideas
  2001-07-12  0:55   ` Rajeev Bector
@ 2001-07-12  0:57     ` H. Peter Anvin
  2001-07-12  1:00       ` Alexander Viro
  2001-07-12  1:02       ` Rajeev Bector
  0 siblings, 2 replies; 9+ messages in thread
From: H. Peter Anvin @ 2001-07-12  0:57 UTC (permalink / raw)
  To: Rajeev Bector; +Cc: linux-kernel, hpa

Rajeev Bector wrote:
> 
> If your driver is in the kernel,
> then you dont need that. All processes
> use system-calls (or ioctls) to send
> messages and when they do recv(),
> they get a pointer to a location
> (where they are mapped to via mmap)
> and they can read directly. In this
> scheme, you dont need any traditional
> UNIX IPC mechanism to work.
> 

And the point of this is?

	-hpa

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: new IPC mechanism ideas
  2001-07-12  0:49 ` H. Peter Anvin
@ 2001-07-12  0:55   ` Rajeev Bector
  2001-07-12  0:57     ` H. Peter Anvin
  0 siblings, 1 reply; 9+ messages in thread
From: Rajeev Bector @ 2001-07-12  0:55 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: linux-kernel, hpa

If your driver is in the kernel,
then you dont need that. All processes
use system-calls (or ioctls) to send
messages and when they do recv(),
they get a pointer to a location
(where they are mapped to via mmap)
and they can read directly. In this
scheme, you dont need any traditional
UNIX IPC mechanism to work.

Thanks,
Rajeev

--- "H. Peter Anvin" <hpa@transmeta.com> wrote:
> Rajeev Bector wrote:
> > 
> > Thanks for your comment, Peter.
> > The problem with using a "driver"
> > process is that now you need
> > another mechanism to communicate
> > with that driver - either
> > message queues or shared
> > memory or something.
> > 
> 
> You need that anyway.
> 
> 	-hpa


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: new IPC mechanism ideas
  2001-07-12  0:10 Rajeev Bector
@ 2001-07-12  0:49 ` H. Peter Anvin
  2001-07-12  0:55   ` Rajeev Bector
  0 siblings, 1 reply; 9+ messages in thread
From: H. Peter Anvin @ 2001-07-12  0:49 UTC (permalink / raw)
  To: Rajeev Bector; +Cc: linux-kernel, hpa

Rajeev Bector wrote:
> 
> Thanks for your comment, Peter.
> The problem with using a "driver"
> process is that now you need
> another mechanism to communicate
> with that driver - either
> message queues or shared
> memory or something.
> 

You need that anyway.

	-hpa

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: new IPC mechanism ideas
@ 2001-07-12  0:10 Rajeev Bector
  2001-07-12  0:49 ` H. Peter Anvin
  0 siblings, 1 reply; 9+ messages in thread
From: Rajeev Bector @ 2001-07-12  0:10 UTC (permalink / raw)
  To: linux-kernel; +Cc: hpa

Thanks for your comment, Peter.
The problem with using a "driver"
process is that now you need
another mechanism to communicate
with that driver - either
message queues or shared
memory or something.

Thanks,
Rajeev


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2001-07-12  1:08 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-07-11  1:49 new IPC mechanism ideas Rajeev Bector
2001-07-11  3:25 ` H. Peter Anvin
2001-07-12  0:10 Rajeev Bector
2001-07-12  0:49 ` H. Peter Anvin
2001-07-12  0:55   ` Rajeev Bector
2001-07-12  0:57     ` H. Peter Anvin
2001-07-12  1:00       ` Alexander Viro
2001-07-12  1:02       ` Rajeev Bector
2001-07-12  1:07         ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).