Re: [PATCH 2/5] /dev/vring: simple userspace-kernel ringbuffer interface.

From: Rusty Russell
Date: Sat Apr 19 2008 - 12:42:04 EST


On Saturday 19 April 2008 05:38:50 Michael Kerrisk wrote:
> On 4/18/08, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > 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
> > ;)

If only there were some kind of, I don't know... summit... for kernel
people...

> > 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.

Indeed. I marked it experimental because of these questions (ie. it's not yet
kernel ABI). Getting everyone's attention is hard tho, so I figured we put
it in as a device and moving to a syscall if and when we feel it's ready.

> > 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.
>
> Well, it helps if he's CCed....

It is compat safe, and we've already extended it once, so I'm reasonably happy
so far. If it were a syscall I'd add a flags arg, for the device it'd be an
ioctl. Starting with the virtio ABI seemed a reasonable first step, because
*we* can use this today even if noone else does.

> I'm happy to work *with someone* on the documentation (pointless to do
> it on my own -- how do I know what Rusty's *intended* behavior for the
> interface is), and review, and testing.

Document coming up...
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/