search for: iterate_devices_fn

...9;DAXDEV_SYNC' flag if all the target > devices of device mapper support synchrononous DAX. If device > mapper consists of both synchronous and asynchronous dax devices, > we don't set 'DAXDEV_SYNC' flag. > > 'dm_table_supports_dax' is refactored to pass 'iterate_devices_fn' > as argument so that the callers can pass the appropriate functions. > > Suggested-by: Mike Snitzer <snitzer at redhat.com> > Signed-off-by: Pankaj Gupta <pagupta at redhat.com> Thanks, and for the benefit of others, passing function pointers like this is perfectly f...

...e-effect of being a setter too. Overloading > > like this could get you in trouble in the future. > > > > Are you certain this is what you want? > > I agree with you. > > > > > Or would it be better to refactor dm_table_supports_dax() to take an > > iterate_devices_fn arg and have callers pass the appropriate function? > > Then have dm_table_set_restrictions() caller do: > > > > if (dm_table_supports_dax(t, device_synchronous, NULL)) > > set_dax_synchronous(t->md->dax_dev); > > > > (NULL arg implies...

...table_set_restrictions and dm_table_determine_type). It is strange to have a getter have a side-effect of being a setter too. Overloading like this could get you in trouble in the future. Are you certain this is what you want? Or would it be better to refactor dm_table_supports_dax() to take an iterate_devices_fn arg and have callers pass the appropriate function? Then have dm_table_set_restrictions() caller do: if (dm_table_supports_dax(t, device_synchronous, NULL)) set_dax_synchronous(t->md->dax_dev); (NULL arg implies dm_table_supports_dax() refactoring would take a int *data pointer...

...patch sets dax device 'DAXDEV_SYNC' flag if all the target devices of device mapper support synchrononous DAX. If device mapper consists of both synchronous and asynchronous dax devices, we don't set 'DAXDEV_SYNC' flag. 'dm_table_supports_dax' is refactored to pass 'iterate_devices_fn' as argument so that the callers can pass the appropriate functions. Suggested-by: Mike Snitzer <snitzer at redhat.com> Signed-off-by: Pankaj Gupta <pagupta at redhat.com> --- drivers/md/dm-table.c | 24 ++++++++++++++++++------ drivers/md/dm.c | 2 +- drivers/md/dm.h...

...t is strange > to have a getter have a side-effect of being a setter too. Overloading > like this could get you in trouble in the future. > > Are you certain this is what you want? I agree with you. > > Or would it be better to refactor dm_table_supports_dax() to take an > iterate_devices_fn arg and have callers pass the appropriate function? > Then have dm_table_set_restrictions() caller do: > > if (dm_table_supports_dax(t, device_synchronous, NULL)) > set_dax_synchronous(t->md->dax_dev); > > (NULL arg implies dm_table_supports_dax() refac...

This patch series is ready to be merged via nvdimm tree as discussed with Dan. We have ack/review on XFS, EXT4 & VIRTIO patches. Device mapper change is also reviewed. Mike, Can you please provide ack for device mapper change i.e patch4. This version has changed implementation for patch 4 as suggested by 'Mike'. Keeping all the existing r-o-bs. Jakob CCed also tested the

This patch series is ready to be merged via nvdimm tree as discussed with Dan. We have ack/review on XFS, EXT4 & VIRTIO patches. Need an ack on device mapper change in patch 4. Mike, Can you please review and ack patch4. This version does not has any additonal code change from v10 and is only rebase of v10 on Linux 5.2-rc4 which is required for patch4. Keeping all the existing

This patch series is ready to be merged via nvdimm tree as discussed with Dan. We have ack/review on XFS, EXT4 device mapper & VIRTIO patches. This version has fix for test bot build failure. Keeping all the existing r-o-bs. Jakob CCed also tested the patch series and confirmed the working of v9. --- This patch series has implementation for "virtio pmem". "virtio

Hi Dan, This series has only change in patch 2 for linux-next build failure. There is no functional change. Keeping all the existing review/acks and reposting the patch series for merging via libnvdimm tree. --- This patch series has implementation for "virtio pmem". "virtio pmem" is fake persistent memory(nvdimm) in guest which allows to bypass the guest page

This patch series is ready to be merged via nvdimm tree as discussed with Dan. We have ack/review on XFS, EXT4 device mapper & VIRTIO patches. This version has minor changes in patch 2. Keeping all the existing r-o-bs. Jakob CCed also tested the patch series and confirmed the working of v9. --- This patch series has implementation for "virtio pmem". "virtio pmem"