Am 22.10.2009 10:31, schrieb Christoph Hellwig: > On Tue, Oct 20, 2009 at 12:12:55PM +0200, Kevin Wolf wrote: >> On that note, falling back to POSIX AIO means that paio_submit is called >> with a Linux AIO aio_ctx. Which works because this parameter is unused >> anyway, but am I the only one to find this ugly? >> >> What is the public interface of paio_submit meant to look like at all? >> If aio_ctx is guaranteed to be unused, why not drop it or pass NULL at >> least? And if it could be used some time in the future, the raw block >> driver needs to be fixed. > > Agreed. Cared to send a patch?
Will do so if we agree to do it this way instead of doing the overkill suggested below. >> That said, I don't even think that the raw block driver is the right >> place to distinguish between different AIO variants. Having a generic >> aio_submit that calls the right AIO driver depending on the context >> would be much cleaner. This would also mean that laio_submit handles the >> fallback to paio_submit on its own, which I think is much cleaner than >> teaching raw about the capabilities of each driver. > > Seems a bit overkill until we get even more AIO variants at least. And > yes, that whole area is really ugly. Yes, it might look like overkill to introduce a abstraction for exactly two backends. I felt the same way. But then, the current implementation just feels totally wrong. It absolutely intransparent when we fall back to paio, and before debugging the bdrv_read/write emulation I didn't even know that we're doing it. And, like I said, why should a block format driver know what AIO method works which way? I'm not insisting on restructuring though if you think that the effort would outweigh the benefit of a cleanup. Kevin
