[dm-devel] [PATCH v4] dm ebs: new block size emulating target

[Mike Snitzer]

On Tue, Mar 10 2020 at  8:39am -0400,
Heinz Mauelshagen <heinzm at redhat.com> wrote:

> On 3/9/20 11:44 PM, Damien Le Moal wrote:
> >On 2020/03/10 7:26, heinzm at redhat.com wrote:
> >>From: Heinz Mauelshagen <heinzm at redhat.com>
> >>
> >>dm ebs: new block size emulating target
> >>
> >>This new target is similar to the linear target except that it emulates
> >>a smaller logical block size on devices with larger ones.  It's main
> >>purpose is to emulate 512 byte sectors on 4K native disks (i.e. 512e).
> >>
> >>See Documentation/admin-guide/device-mapper/dm-ebs.rst for details.
> >>
> >>Changes versus version 3 sent on 2/19/2020:
> >>
> >>- document 'struct ebs_c' and rename its blocksize and block shift fields
> >>- inline functions (e.g. __nr_blocks())
> >>- adjust __ebs_rw_bvec() function header format
> >>- access page_address() after bv_page check; typo
> >>- avoid superfluous check defining bi_status in __ebs_process_bios()
> >>- correct indentation
> >>- avoid op_is_flush() causing REQ_FUA bios to be
> >>   remapped hence not processed by the target
> >>- call flush_dcache_page() correlated with memcpy() to ensure
> >>   D-cache aliasing as of cache and TLB flushing guidelines
> >>- comments
> >Generally, the change log is not added as part of the commit message and
> >mentioned after the "---" and all change logs "from v1", "from v2" etc kept so
> >that everybody can see the progression.
> 
> 
> As of the kernel patch submission guidelines it should be part of:
> 
> 'Describe your changes in imperative mood, e.g. “make xyzzy do
> frotz” instead of “[This patch] makes xyzzy do frotz” or “[I]
> changed xyzzy to do frotz”, as if you are giving orders to the
> codebase to change its behaviour.'
> 
> The limitation to the v3 -> v4 changes was negotiated with Mike.
> I'll keep it as is until further decision.

Right but I said I need a useful header that you refine over time; and
then the incremental changes between versions in the cut (--) section
like Damien pointed out.

If you have a new revision definitely do stack the incremental change
info on the info for previous revisions.

Thanks,
Mike