On Sun, Sep 01, 2019 at 01:44:00PM -0700, Darrick J. Wong wrote: > Would you mind rebasing the remaining patches against iomap-for-next and > sending that out? I'll try to get to it before I go on vacation 6 - 15 > Sept. Ok. Testing right now, but the rebase was trivial. > Admittedly I think the controversial questions are still "How much > writeback code are we outsourcing to iomap anyway?" and "Do we want to > do the added stress of keeping that going without breaking everyone > else"? IOWs, more philosophical than just the mechanics of porting code > around. At least as far as I'm concerned the more code that is common the better so that I don't have to fix up 4 badly maintained half-assed forks of the same code (hello mpage, ext4 and f2fs..). > I still want a CONFIG_IOMAP_DEBUG which turns on stricter checking of > the iomap(s) that ->begin_iomap pass to the actor, if you have the time; > I for one am starting to forget exactly what are the valid combinations > of iomap flag inputs that ->begin_iomap has to handle for a given actor > and what are the valid imaps for each actor that it can pass back. :) I was actually thinking of killing the input IOMAP_ types entirely, as that "flags" model just doesn't scale, and instead have more iomap_ops instances in the callers. But that is just a vague idea at the moment. I'll need some more time to think about it.
