Re: Block layer projects that I haven't had time for

[Kent Overstreet <kmo@daterainc.com>]

On Thu, Dec 04, 2014 at 12:00:27PM +0100, Dongsu Park wrote:
> Hi Kent,
> 
> On 23.11.2014 20:16, Kent Overstreet wrote:
> > Since I'm starting to resign myself to the fact that I'm probably not going to
> > have much time for upstream development again any time soon, I figured maybe I
> > should try writing down all the things I was working on or planning on working
> > on in case someone else is feeling ambitious and looking for things to work on.
> > 
> > If anyone wants to take up any of this stuff, feel free to take my half baked
> > code and do whatever you want with it, or ping me for ideas/guidance.
> 
> I'm interested in taking up your work and further implement it.
> IMHO the 1st and 2nd items, making generic_make_request() take arbitrarily
> sized bios, are the essential ones. With those changes, individual block
> drivers wouldn't have to define ->merge_bvec_fn() any more.

Cool! Yeah, things get a lot simpler for a lot of code.

> Playing a little with your block_stuff tree based on 3.15, however,
> I think there still seems to be a couple of issues.
> First of all, it doesn't work with virtio-blk. A testing Qemu VM panics
> at the very early stage of booting. This issue should be addressed as
> the first step, so that other parts can be tested.

Really? I was testing with virtio-blk, that's odd..

> Moreover, I've already tried to rebase these patches on top of current
> mainline, 3.18-rc7. It's now compilable, but it seems to introduce
> more bugs about direct-IO. I didn't manage to find out the reason.
> I'd need to also look at the previous review comments in [1], [2].
> 
> Don't you have other trees based on top of 3.17 or higher?
> If not, can I create my own tree based on 3.18-rc7 to publish?

Yeah, I'd post what you have now and I'll try and take a look.