On 4/18/08, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sat, 19 Apr 2008 00:32:39 +1000 Rusty Russell <rusty@xxxxxxxxxxxxxxx> 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.
Well, it helps if he's CCed....
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.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
