Re: [RFC PATCH 10/17] block: introduce bdev_dax_direct_access()

2017-02-01 Thread Christoph Hellwig
On Wed, Feb 01, 2017 at 01:21:40AM -0800, Dan Williams wrote: > > In/Out parameters are always a bit problematic in terms of API clarity. > > And updating a device-relative address with an absolute physical one > > sounds like an odd API for sure. > > Yes, it does, and I thought better of it

Re: [RFC PATCH 10/17] block: introduce bdev_dax_direct_access()

2017-02-01 Thread Dan Williams
On Wed, Feb 1, 2017 at 12:10 AM, Christoph Hellwig wrote: > On Mon, Jan 30, 2017 at 10:16:29AM -0800, Dan Williams wrote: >> Ok, now that dax_map_atomic() is gone, it's much easier to remove >> struct blk_dax_ctl. >> >> We can also move the partition alignment checks to be a one-time

Re: [RFC PATCH 10/17] block: introduce bdev_dax_direct_access()

2017-02-01 Thread Christoph Hellwig
On Mon, Jan 30, 2017 at 10:16:29AM -0800, Dan Williams wrote: > Ok, now that dax_map_atomic() is gone, it's much easier to remove > struct blk_dax_ctl. > > We can also move the partition alignment checks to be a one-time check > at bdev_dax_capable() time and kill bdev_dax_direct_access() in

Re: [RFC PATCH 10/17] block: introduce bdev_dax_direct_access()

2017-01-30 Thread Dan Williams
On Mon, Jan 30, 2017 at 4:32 AM, Christoph Hellwig wrote: > On Sat, Jan 28, 2017 at 12:36:58AM -0800, Dan Williams wrote: >> Provide a replacement for bdev_direct_access() that uses >> dax_operations.direct_access() instead of >> block_device_operations.direct_access(). Once all