netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ludovico Gardenghi <garden@cs.unibo.it>
To: david@lang.hm
Cc: Renzo Davoli <renzo@cs.unibo.it>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] IPN: Inter Process Networking
Date: Mon, 17 Dec 2007 11:47:06 +0100	[thread overview]
Message-ID: <20071217104706.GA10966@ripieno.somiere.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0712170327410.4467@asgard>

On Mon, Dec 17, 2007 at 03:31:48AM -0800, david@lang.hm wrote:

> wouldn't it be better to just add the ability for multiple writers to send 
> to the same pipe, and then have all of them splice into the output of that 
> pipe? this would give the same data-agnostic communication that you are 
> looking for, and with the minor detail that software would have to filter 
> out messages that they send, would appear to meet all the goals you are 
> looking at, useing existing kernel features that are designed to be very 
> high performance.

Being able to define both filtering policies (think of a virtual
ethernet layer 2 switch, for instance. We have situations where dozens
or hundreds of virtual cables are connected to the same switch, it would
be much, much slower if you had to awake all the user processes for each
single non-broadcast ethernet frame, and send them useless data) and
delivery guarantees (lossless vs best-effort delivery) are not minor
details in our opinion.

We might have added a level2 virtual ethernet switch at kernel
level, but it seemed to specific. With a minor effort we have split the
"dumb" bus (IPN) and the ability to process specific structured data
with specific policies (sub-modules as kvde_switch).

We surely may adapt existing features (AF_UNIX, or pipes) but they offer
a quite established interface and semantics and we think it should be
better to add a new family. This would prevent from breaking what
already exists and leaving more freedom in defining the new family
according to needs.

As for ptrace vs utrace: ptrace has been designed for debugging; trying
to bend it to be fit for virtualization is likely to end up in an
intricated interface and implementation. utrace has been designed in a
much more general way. You can implement ptrace over utrace, but you can
use utrace also for virtualization in a cleaner, simpler and more
efficient way. Why not?

Ludovico
-- 
<garden@acheronte.it>        #acheronte (irc.freenode.net) ICQ: 64483080
GPG ID: 07F89BB8          Jabber: gardengl@gmail.com Yahoo: gardenghelle
-- This is signature nr. 3556

  reply	other threads:[~2007-12-17 10:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-17  9:24 [PATCH 0/1] IPN: Inter Process Networking Renzo Davoli
2007-12-17  9:27 ` [PATCH 1/1] " Renzo Davoli
2007-12-17 15:47   ` Paul E. McKenney
2007-12-17 11:31 ` [PATCH 0/1] " david
2007-12-17 10:47   ` Ludovico Gardenghi [this message]
2007-12-17 12:10     ` david
2007-12-17 11:50       ` Ludovico Gardenghi
2007-12-17 21:15         ` david

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071217104706.GA10966@ripieno.somiere.org \
    --to=garden@cs.unibo.it \
    --cc=david@lang.hm \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=renzo@cs.unibo.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).