linux-kernel - Re: [patch v3 1/1] md: Software Raid autodetect dev list not array

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]

Date:	Tue, 28 Aug 2007 09:15:05 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Michael Evans <mjevans1983@...il.com>
CC:	Bill Davidsen <davidsen@....com>,
	"Michael J. Evans" <mjevans1983@...cast.net>,
	Neil Brown <neilb@...e.de>, Ingo Molnar <mingo@...hat.com>,
	linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch v3 1/1] md: Software Raid autodetect dev list not array

Michael Evans wrote:
> On 8/28/07, Bill Davidsen <davidsen@....com> wrote:
>> Michael Evans wrote:
>>> Oh, I see.  I forgot about the changelogs.  I'd send out version 5
>>> now, but I'm not sure what kernel version to make the patch against.
>>> 2.6.23-rc4 is on kernel.org and I don't see any git snapshots.
>>> Additionally I never could tell what git tree was the 'mainline' as it
>>> isn't labeled with such a keyword (at least in the list of git trees I
>>> saw).
>> 
>> I suspect you wait for 2.5.23 release, or send it to AKPM for inclusion
>> in an "-mm" kernel. That's probably desirable, anyway.
>>
>> --
> 
> There's another list I should CC to?  Or does the section maintainer
> do that when they're happy with the patch?

Not another list; just cc: akpm@...ux-foundation.org so that he can merge
it into the -mm kernel patches for testing.  Most patches cook in the -mm
kernel(s) before they are merged into mainline.

Then generally the subsystem maintainer(s) are responsible for sending
patches on to Linus for merging into mainline, if/when they are happy
with the patch and they think that it has been tested enough.

Mainline progresses (roughly, e.g.) like so:

2.6.22
then patches are applied and we get (possibly) daily snapshots from git, like
2.6.22-git1, 2.6.22-git2, ...

After the primary 2-week merge window for new code (i.e., not just bug fixes),
we get 2.6.23-rc1.
Then as more patches are merged, we get 2.6.23-rc1-gitN...

Then 2.6.23-rc2 ... 2.6.23-rc2-gitN...

2.6.23-rc3 ... 2.6.23-rc3-gitN...

blah blah blah

You can use git to download and track the mainline kernel changes,
or you can download tarballs + patches (patches for each -rc as well as
for each -gitN snapshot) and apply the patches yourself or use a
script to do it. (like 'ketchup': http://www.selenic.com/ketchup/wiki/;
or like http://www.xenotime.net/linux/scripts/grab_kernel)

In general, patches should be made against latest/recent kernels, either
current git (cloned or updated via pull), or against recent patches
+ git snapshot if there is a git snapshot that is applicable.
Immediately after 2.6.23-rcN, there is no applicable git snapshot to
be applied (well, a few hours later there may be).

Sometimes it is appropriate to make patches against the -mm kernel
patchset, but only if the patch is for code that is only in that
kernel patchset (or if Andrew asks for a patch to be updated against
-mm).  [This is a mostly rough generalization.]  Andrew normally
takes patches against mainline and coerces them into -mm if coercion
is needed.

-- 
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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/