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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130829033023.GH4872@agk-dp.fab.redhat.com>
Date:	Thu, 29 Aug 2013 04:30:23 +0100
From:	Alasdair G Kergon <agk@...hat.com>
To:	Akira Hayakawa <ruby.wktk@...il.com>
Cc:	dm-devel@...hat.com, Greg KH <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, kernelnewbies@...nelnewbies.org
Subject: Re: [dm-devel] [RFC] dm-lc: plan to go to staging

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/