lkml.org 
[lkml]   [2008]   [Apr]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface.
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?


\
 
 \ /
  Last update: 2008-04-18 21:03    [W:0.092 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site