[dm-devel] [RFC] dm-lc: plan to go to staging

[Mikulas Patocka]

Another idea:

Make the interface of dm-lc (the arguments to constructor, messages and 
the status line) the same as dm-cache, so that they can be driven by the 
same userspace code.

Mikulas


On Thu, 29 Aug 2013, Alasdair G Kergon wrote:

> On Wed, Aug 28, 2013 at 07:05:55PM -0700, Greg KH wrote:
> > For staging drivers, I need a TODO file that lists
> > what needs to be done to the code to get it into a mergable state for
> > the "real" part of the kernel,
> 
> Two simple requirements before putting your proof-of-concept into staging
> if you want to work that way:
> 
> 1) Drop the major version number to 0.  Version 1 is reserved for
> supported modules.
> 
> 2) Agree a new and meaningful target name with us so you don't have to
> change it later.  "lc" means nothing, I'm afraid.
> 
> Then in general terms, you should continue to compare your device-mapper
> target with the existing targets and where there are differences, either
> change your target to be like something that already exists, or be ready
> to explain why that can't or shouldn't be done.
> 
> In particular, the interface and architecture will need substantial
> changes and working these out should be your highest priority.
> 
> For example, you write:
> 
>   Be careful, you MUST create all the LVs as the destinations of
>   the dirty blocks on the cache device before this operation.  Otherwise,
>   the kernel may crash.
> 
> I read a statement like that as an indication of an interface or
> architectural problem.  The device-mapper approach is to 'design out'
> problems, rather than relying on users not doing bad things.
> Study the existing interfaces used by other targets to understand
> some approaches that proved successful, then decide which ones
> come closest to your needs.
> 
> (Your code also needs many more comments inline to explain what it does
> and how it works.)
> 
> The documentation file will eventually need rewriting to follow the same
> format as the other targets recently added to the kernel.  We document
> the kernel interface rather than any particular userspace tools, which
> just have the status of convenient examples.
> 
> Another little thing I noticed: look into using something like
> __dm_bless_for_disk() for your metadata and clearly segregate your
> on-disk structures and document the layout.
> 
> Alasdair
> 
> --
> dm-devel mailing list
> dm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>