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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/dm-devel > -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
