From: Anthony Liguori <aliguori@us.ibm.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
kvm@vger.kernel.org, Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH][RFC] vmchannel a data channel between host and guest.
Date: Tue, 14 Oct 2008 08:50:48 -0500 [thread overview]
Message-ID: <48F4A3B8.8050603@us.ibm.com> (raw)
In-Reply-To: <20081014090540.GB13153@redhat.com>
Gleb Natapov wrote:
> On Mon, Oct 13, 2008 at 01:32:35PM -0500, Anthony Liguori wrote:
>
>>
> netlink was designed to be interface to userspace and is used like this
> by different subsystems (not just network). What full blown socket (and
> by that I presume you mean new address family) will give you over netlink?
> File system? We need a simple stream semantics is this justify another
> virtual file system? The choice was between char device and netlink.
> Nelink was simpler and gives broadcast as a bonus.
>
The problem that you aren't solving, that IMHO is critical to solve, is
the namespace issue. How do you determine who gets to use what channel
in userspace and in the host? It's not a problem when you just have one
tool, but if you expect people to start using this interface,
arbitrating it quickly becomes a problem.
sockets have a concept of addressing and a vfs has a natural namespace.
That's what I was suggesting those interfaces.
>
>> Having a limit of only 4 links seems like a problem to me too.
>>
>>
> This can be easily extended.
>
There shouldn't be an inherent limit in the userspace interface.
Regards,
Anthony Liguori
next prev parent reply other threads:[~2008-10-14 13:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-12 12:45 [PATCH][RFC] vmchannel a data channel between host and guest Gleb Natapov
2008-10-13 18:32 ` Anthony Liguori
2008-10-14 9:05 ` Gleb Natapov
2008-10-14 13:50 ` Anthony Liguori [this message]
2008-10-14 17:59 ` Gleb Natapov
2008-10-14 18:16 ` Anthony Liguori
2008-10-15 12:58 ` Gleb Natapov
2008-10-15 14:02 ` Anthony Liguori
2008-10-16 8:41 ` Gleb Natapov
2008-10-15 14:02 ` Anthony Liguori
2008-10-15 14:18 ` Andrew Biggadike
2008-10-15 14:30 ` Gleb Natapov
2008-10-15 14:30 ` Gleb Natapov
2008-10-15 15:00 ` Andrew Biggadike
2008-10-15 15:42 ` Gleb Natapov
2008-10-15 15:56 ` Anthony Liguori
2008-10-16 8:54 ` Gleb Natapov
2008-10-15 15:56 ` Anthony Liguori
2008-10-15 16:59 ` Andrew Biggadike
2008-10-15 16:59 ` Andrew Biggadike
2008-10-15 14:18 ` Andrew Biggadike
2008-10-15 12:58 ` Gleb Natapov
2008-10-14 18:16 ` Anthony Liguori
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=48F4A3B8.8050603@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.