From: Andrew Morton <akpm@linux-foundation.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Max Krasnyansky <maxk@qualcomm.com>,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface.
Date: Fri, 18 Apr 2008 11:59:59 -0700 [thread overview]
Message-ID: <20080418115959.6b8fdfa7.akpm@linux-foundation.org> (raw)
In-Reply-To: <200804190032.39626.rusty@rustcorp.com.au>
On Sat, 19 Apr 2008 00:32:39 +1000 Rusty Russell <rusty@rustcorp.com.au> wrote:
> > Isn't this kinda-sorta like what a relayfs file does? The oprofile
> > buffers? etc? Nothing in common at all, no hope?
>
> An excellent question, but I thought the modern kernel etiquette was to only
> comment on whitespace and formatting, and call it "review"? :)
>
> Yes, kinda-sorta in that it's a ring buffer. No, in that it's bidir and
> consumption can be out-of-order (kind of important for I/O buffers).
>
> But the reason I'm not proposing it as a syscall is that I'm not convinced
> it's the One True Solution which everyone should be using. Time will tell:
> it's clearly not tied to tun and it's been generically useful for virtual
> I/O, but history has not been kind to new userspace interfaces.
This is may be our third high-bandwidth user/kernel interface to transport
bulk data ("hbukittbd") which was implemented because its predecessors
weren't quite right. In a year or two's time someone else will need a
hbukittbd and will find that the existing three aren't quite right and will
give us another one. One day we need to stop doing this ;)
It could be that this person will look at Rusty's hbukittbd and find that
it _could_ be tweaked to do what he wants, but it's already shipping and
it's part of the kernel API and hence can't be made to do what he wants.
So I think it would be good to plonk the proposed interface on the table
and have a poke at it. Is it compat-safe? Is it extensible in a
backward-compatible fashion? Are there future-safe changes we should make
to it? Can Michael Kerrisk understand, review and document it? etc.
You know what I'm saying ;) What is the proposed interface?
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: netdev@vger.kernel.org, Max Krasnyansky <maxk@qualcomm.com>,
virtualization@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface.
Date: Fri, 18 Apr 2008 11:59:59 -0700 [thread overview]
Message-ID: <20080418115959.6b8fdfa7.akpm@linux-foundation.org> (raw)
In-Reply-To: <200804190032.39626.rusty@rustcorp.com.au>
On Sat, 19 Apr 2008 00:32:39 +1000 Rusty Russell <rusty@rustcorp.com.au> wrote:
> > Isn't this kinda-sorta like what a relayfs file does? The oprofile
> > buffers? etc? Nothing in common at all, no hope?
>
> An excellent question, but I thought the modern kernel etiquette was to only
> comment on whitespace and formatting, and call it "review"? :)
>
> Yes, kinda-sorta in that it's a ring buffer. No, in that it's bidir and
> consumption can be out-of-order (kind of important for I/O buffers).
>
> But the reason I'm not proposing it as a syscall is that I'm not convinced
> it's the One True Solution which everyone should be using. Time will tell:
> it's clearly not tied to tun and it's been generically useful for virtual
> I/O, but history has not been kind to new userspace interfaces.
This is may be our third high-bandwidth user/kernel interface to transport
bulk data ("hbukittbd") which was implemented because its predecessors
weren't quite right. In a year or two's time someone else will need a
hbukittbd and will find that the existing three aren't quite right and will
give us another one. One day we need to stop doing this ;)
It could be that this person will look at Rusty's hbukittbd and find that
it _could_ be tweaked to do what he wants, but it's already shipping and
it's part of the kernel API and hence can't be made to do what he wants.
So I think it would be good to plonk the proposed interface on the table
and have a poke at it. Is it compat-safe? Is it extensible in a
backward-compatible fashion? Are there future-safe changes we should make
to it? Can Michael Kerrisk understand, review and document it? etc.
You know what I'm saying ;) What is the proposed interface?
next prev parent reply other threads:[~2008-04-18 18:59 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-18 4:33 [PATCH 0/5] High-speed tun receive and xmit Rusty Russell
2008-04-18 4:35 ` [PATCH 1/5] virtio: put last_used and last_avail index into ring itself Rusty Russell
2008-04-18 4:39 ` [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface Rusty Russell
2008-04-18 4:41 ` [PATCH 3/5] /dev/vring limit and base ioctls Rusty Russell
2008-04-18 4:41 ` Rusty Russell
2008-04-18 4:42 ` [PATCH 4/5] tun: vringfd receive support Rusty Russell
2008-04-18 4:42 ` Rusty Russell
2008-04-18 4:43 ` [PATCH 5/5] tun: vringfd xmit support Rusty Russell
2008-04-18 4:43 ` Rusty Russell
2008-04-18 4:43 ` Rusty Russell
2008-04-18 11:31 ` Andrew Morton
2008-04-18 11:31 ` Andrew Morton
2008-04-18 15:15 ` Rusty Russell
2008-04-18 15:15 ` Rusty Russell
2008-04-18 16:24 ` Ray Lee
2008-04-18 16:24 ` Ray Lee
2008-04-18 19:06 ` Andrew Morton
2008-04-18 19:06 ` Andrew Morton
2008-04-19 14:41 ` Rusty Russell
2008-04-19 14:41 ` Rusty Russell
2008-04-19 17:51 ` Andrew Morton
2008-04-19 17:51 ` Andrew Morton
2008-04-19 1:54 ` Andrew Morton
2008-04-19 1:54 ` Andrew Morton
2008-04-18 11:46 ` pradeep singh rautela
2008-04-18 14:25 ` Ray Lee
2008-04-18 14:25 ` Ray Lee
2008-04-18 18:01 ` pradeep singh rautela
2008-04-18 18:01 ` pradeep singh rautela
2008-04-18 11:18 ` [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface Andrew Morton
2008-04-18 14:32 ` Rusty Russell
2008-04-18 14:32 ` Rusty Russell
2008-04-18 18:59 ` Andrew Morton [this message]
2008-04-18 18:59 ` Andrew Morton
2008-04-18 19:38 ` Michael Kerrisk
2008-04-18 19:38 ` Michael Kerrisk
2008-04-19 16:41 ` Rusty Russell
2008-04-20 0:16 ` David Miller
2008-04-20 0:16 ` David Miller
2008-04-19 16:41 ` Rusty Russell
2008-04-19 15:02 ` Jonathan Corbet
2008-04-19 15:02 ` Jonathan Corbet
2008-04-18 11:18 ` Andrew Morton
2008-04-19 10:22 ` Evgeniy Polyakov
2008-04-19 16:05 ` Rusty Russell
2008-04-19 16:05 ` Rusty Russell
2008-04-19 16:33 ` Evgeniy Polyakov
2008-04-19 16:33 ` Evgeniy Polyakov
2008-04-19 16:45 ` Rusty Russell
2008-04-19 16:45 ` Rusty Russell
2008-04-19 10:22 ` Evgeniy Polyakov
2008-04-18 4:39 ` Rusty Russell
2008-04-18 4:35 ` [PATCH 1/5] virtio: put last_used and last_avail index into ring itself Rusty Russell
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=20080418115959.6b8fdfa7.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxk@qualcomm.com \
--cc=netdev@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.org \
/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.