On 10/21/2021 5:49 PM, Jane Chu wrote: > On 10/21/2021 4:27 AM, Christoph Hellwig wrote: >> On Wed, Oct 20, 2021 at 06:10:57PM -0600, Jane Chu wrote: >>> Prepare dax_copy_to/from_iter() APIs with DAXDEV_F_RECOVERY flag >>> such that when the flag is set, the underlying driver implementation >>> of the APIs may deal with potential poison in a given address >>> range and read partial data or write after clearing poison. >> >> FYI, I've been wondering for a while if we could just kill off these >> methods entirely. Basically the driver interaction consists of two >> parts: >> >> a) wether to use the flushcache/mcsafe variants of the generic helpers >> b) actually doing remapping for device mapper >> >> to me it seems like we should handle a) with flags in dax_operations, >> and only have a remap callback for device mapper. That way we'd avoid >> the indirect calls for the native case, and also avoid tons of >> boilerplate code. "futher decouple DAX from block devices" series >> already massages the device mapper into a form suitable for such >> callbacks. >> > > I've looked through your "futher decouple DAX from block devices" series > and likes the use of xarray in place of the host hash list. > Which upstream version is the series based upon? > If it's based on your development repo, I'd be happy to take a clone > and rebase my patches on yours if you provide a link. Please let me > know the best way to cooperate. > > That said, I'm unclear at what you're trying to suggest with respect > to the 'DAXDEV_F_RECOVERY' flag. The flag came from upper dax-fs > call stack to the dm target layer, and the dm targets are equipped > with handling pmem driver specific task, so it appears that the flag Apologies. The above line should be "..., and the dm targets are _not_ equipped with handling pmem driver specific task," -jane > would need to be passed down to the native pmem layer, right? > Am I totally missing your point? > > thanks, > -jane >
