On 12/11/20 11:03 AM, Hannes Reinecke wrote: > On 12/11/20 6:04 PM, Jens Axboe wrote: >> On 12/11/20 9:56 AM, Hannes Reinecke wrote: >>> On 12/11/20 5:33 PM, Jens Axboe wrote: >>>> On 12/11/20 9:30 AM, Mike Snitzer wrote: >>>>> While I still think there needs to be a proper _upstream_ consumer of >>>>> blk_interposer as a condition of it going in.. I'll let others make the >>>>> call. >>>> >>>> That's an unequivocal rule. >>>> >>>>> As such, I'll defer to Jens, Christoph and others on whether your >>>>> minimalist blk_interposer hook is acceptable in the near-term. >>>> >>>> I don't think so, we don't do short term bandaids just to plan on >>>> ripping that out when the real functionality is there. IMHO, the dm >>>> approach is the way to go - it provides exactly the functionality that >>>> is needed in an appropriate way, instead of hacking some "interposer" >>>> into the core block layer. >>>> >>> Which is my plan, too. >>> >>> I'll be working with the Veeam folks to present a joint patchset >>> (including the DM bits) for the next round. >> >> Just to be clear, core block additions for something that dm will >> consume is obviously fine. Adding this as block layer functionality than >> then exposes an application API for setting it up, tearing down, etc - >> that is definitely NOT >> > That was never my intention. > Any consumers of this thing would need to be in-kernel. > If that was your concern. Yep, that is/was indeed my concern! -- Jens Axboe
