Hi,
2) it's impossible to add new interfaces and we need a vectored read/write
operation to properly support a zero-copy API.
I'm eager to try vectored block ops for the xenbus block backend.
It performs at least as well as the current posix-aio code (in some
circumstances, even better).
Well, I see a massive slowdown when switching from sync to aio in the
xen backend code. I think the reason is that due to the lack of a
vectored interface (and thus /me submitting separate aio requests for
each iovec element) stuff gets parallelized *way* too much and disk seek
times are killing me.
My only concern here is non-Linux Unices like FreeBSD. They have kernel support
for posix-aio. Since we cannot extend those interfaces though, I think that
even on those platforms we should still use a thread pool.
Which might change some day in the future when we manage to get iovec
support into posix-aio specs.
I think the interface should use qemu-prefixed function and struct
names. The we can trivially map them to a system-provided aio
implementation without worrying about name clashes.