Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
Michael Evans wrote: On 8/28/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: Michael Evans wrote: On 8/28/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: Michael Evans wrote: On 8/28/07, Bill Davidsen <[EMAIL PROTECTED]> 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. Gentoo's mm-sources is version 2.6.23-rc3-mm1, which I'd guess is close enough for an area like this. Given that I didn't need to make any changes to the patch should I just submit it to the mm for testing without rebooting in to an mm-sources kernel? I need to schedule when I do that so it would take me overnight to do so. Yes, I think that you can go ahead with that, but it's up to the subsystem maintainers where/when it goes from there. -- ~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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On 8/28/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > Michael Evans wrote: > > On 8/28/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > >> Michael Evans wrote: > >>> On 8/28/07, Bill Davidsen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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. > >> > > > > So I should look at the git documentation again, try to pull down > > Andrew's latest -mm, and see what I need to change (if anything) to > > patch against it? (I would probably only verify that boots once my > > self given the other testing this has already seen and how often mm > > breaks things my mythtv box likes, such as nvidia-drivers, etc,) > > -mm is available only as a patchset, not via git. > There has been a git version of it, but it's not currently working and > hasn't been for 2 months or so. > > I mostly use the grab_kernel script that I mentioned. It knows how > to download linux-2.6.M and how to apply -rcN, -gitN, and/or -mmN > patches to the base (linux-2.6.M). > > E.g.: > grab_kernel 2.6.23-rc3-git6 $PWD > or > grab_kernel 2.6.23-rc3-mm1 $PWD > > > -- > ~Randy > *** Remember to use Documentation/SubmitChecklist when testing your code *** > Gentoo's mm-sources is version 2.6.23-rc3-mm1, which I'd guess is close enough for an area like this. Given that I didn't need to make any changes to the patch should I just submit it to the mm for testing without rebooting in to an mm-sources kernel? I need to schedule when I do that so it would take me overnight to do so. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
Michael Evans wrote: On 8/28/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: Michael Evans wrote: On 8/28/07, Bill Davidsen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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. So I should look at the git documentation again, try to pull down Andrew's latest -mm, and see what I need to change (if anything) to patch against it? (I would probably only verify that boots once my self given the other testing this has already seen and how often mm breaks things my mythtv box likes, such as nvidia-drivers, etc,) -mm is available only as a patchset, not via git. There has been a git version of it, but it's not currently working and hasn't been for 2 months or so. I mostly use the grab_kernel script that I mentioned. It knows how to download linux-2.6.M and how to apply -rcN, -gitN, and/or -mmN patches to the base (linux-2.6.M). E.g.: grab_kernel 2.6.23-rc3-git6 $PWD or grab_kernel 2.6.23-rc3-mm1 $PWD -- ~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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On 8/28/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > Michael Evans wrote: > > On 8/28/07, Bill Davidsen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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. > So I should look at the git documentation again, try to pull down Andrew's latest -mm, and see what I need to change (if anything) to patch against it? (I would probably only verify that boots once my self given the other testing this has already seen and how often mm breaks things my mythtv box likes, such as nvidia-drivers, etc,) > Mainline progresses (roughly, e.g.) like so: > I knew about the progression order (but not timing) of the non-git side of it, but it was helpful to have the whole thing spelled out, thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
Michael Evans wrote: On 8/28/07, Bill Davidsen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On 8/28/07, Bill Davidsen <[EMAIL PROTECTED]> 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. > > -- > bill davidsen <[EMAIL PROTECTED]> > CTO TMR Associates, Inc > Doing interesting things with small computers since 1979 > > There's another list I should CC to? Or does the section maintainer do that when they're happy with the patch? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On Tuesday 28 August 2007, Jan Engelhardt wrote: > > On Aug 28 2007 06:08, 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. > > 2.6.23-rc4 is a snapshot in itself, a tagged one at that. > Just use git pull to get the latest, which is always good. > Or git fetch; git checkout 2.6.23-rc4; if you need that particular one. > > >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). > > /torvalds/linux-2.6.git or so; yes, it's not clearly marked. Then again, why? > /Mainline is tarballs for most people, and they don't want to go deeper ;-) > > > Jan > -- > Thank you, I'll try to keep that in mind the next time I try to use git. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
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. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On Aug 28 2007 06:08, 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. 2.6.23-rc4 is a snapshot in itself, a tagged one at that. Just use git pull to get the latest, which is always good. Or git fetch; git checkout 2.6.23-rc4; if you need that particular one. >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). /torvalds/linux-2.6.git or so; yes, it's not clearly marked. Then again, why? /Mainline is tarballs for most people, and they don't want to go deeper ;-) Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On 8/27/07, Randy Dunlap <[EMAIL PROTECTED]> wrote: > Michael J. Evans wrote: > > On Monday 27 August 2007, Randy Dunlap wrote: > >> On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote: > >> > >>> = > >>> --- linux/drivers/md/md.c.orig 2007-08-21 03:19:42.511576248 -0700 > >>> +++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700 > >>> @@ -24,4 +24,6 @@ > >>> > >>> + - autodetect dev list not array: Michael J. Evans > > <[EMAIL PROTECTED]> > >>> + > >> Nowadays we use an SCM for such comments, not the source file(s). > > > > SCM? Is this automatic, where do I go to see it? > > See Documentation/SubmittingPatches: > 14) The canonical patch format: > > The canonical patch message body contains the following: > > - A "from" line specifying the patch author. > > - An empty line. > > - The body of the explanation, which will be copied to the > permanent changelog to describe this patch. > > - The "Signed-off-by:" lines, described above, which will > also go in the changelog. > > - A marker line containing simply "---". > > - Any additional comments not suitable for the changelog. > > - The actual patch (diff output). > > > so just put whatever you want to be in the permanent SCM logs > into the "body of the explanation" part of the email. > > > -- > ~Randy > *** Remember to use Documentation/SubmitChecklist when testing your code *** > 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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On 8/27/07, Randy Dunlap [EMAIL PROTECTED] wrote: Michael J. Evans wrote: On Monday 27 August 2007, Randy Dunlap wrote: On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote: = --- linux/drivers/md/md.c.orig 2007-08-21 03:19:42.511576248 -0700 +++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700 @@ -24,4 +24,6 @@ + - autodetect dev list not array: Michael J. Evans [EMAIL PROTECTED] + Nowadays we use an SCM for such comments, not the source file(s). SCM? Is this automatic, where do I go to see it? See Documentation/SubmittingPatches: 14) The canonical patch format: The canonical patch message body contains the following: - A from line specifying the patch author. - An empty line. - The body of the explanation, which will be copied to the permanent changelog to describe this patch. - The Signed-off-by: lines, described above, which will also go in the changelog. - A marker line containing simply ---. - Any additional comments not suitable for the changelog. - The actual patch (diff output). so just put whatever you want to be in the permanent SCM logs into the body of the explanation part of the email. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** 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). - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On Aug 28 2007 06:08, 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. 2.6.23-rc4 is a snapshot in itself, a tagged one at that. Just use git pull to get the latest, which is always good. Or git fetch; git checkout 2.6.23-rc4; if you need that particular one. 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). /torvalds/linux-2.6.git or so; yes, it's not clearly marked. Then again, why? /Mainline is tarballs for most people, and they don't want to go deeper ;-) Jan -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On Tuesday 28 August 2007, Jan Engelhardt wrote: On Aug 28 2007 06:08, 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. 2.6.23-rc4 is a snapshot in itself, a tagged one at that. Just use git pull to get the latest, which is always good. Or git fetch; git checkout 2.6.23-rc4; if you need that particular one. 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). /torvalds/linux-2.6.git or so; yes, it's not clearly marked. Then again, why? /Mainline is tarballs for most people, and they don't want to go deeper ;-) Jan -- Thank you, I'll try to keep that in mind the next time I try to use git. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On 8/28/07, Bill Davidsen [EMAIL PROTECTED] 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. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 There's another list I should CC to? Or does the section maintainer do that when they're happy with the patch? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
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. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
Michael Evans wrote: On 8/28/07, Bill Davidsen [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On 8/28/07, Randy Dunlap [EMAIL PROTECTED] wrote: Michael Evans wrote: On 8/28/07, Bill Davidsen [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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. So I should look at the git documentation again, try to pull down Andrew's latest -mm, and see what I need to change (if anything) to patch against it? (I would probably only verify that boots once my self given the other testing this has already seen and how often mm breaks things my mythtv box likes, such as nvidia-drivers, etc,) Mainline progresses (roughly, e.g.) like so: I knew about the progression order (but not timing) of the non-git side of it, but it was helpful to have the whole thing spelled out, thank you. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
Michael Evans wrote: On 8/28/07, Randy Dunlap [EMAIL PROTECTED] wrote: Michael Evans wrote: On 8/28/07, Bill Davidsen [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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. So I should look at the git documentation again, try to pull down Andrew's latest -mm, and see what I need to change (if anything) to patch against it? (I would probably only verify that boots once my self given the other testing this has already seen and how often mm breaks things my mythtv box likes, such as nvidia-drivers, etc,) -mm is available only as a patchset, not via git. There has been a git version of it, but it's not currently working and hasn't been for 2 months or so. I mostly use the grab_kernel script that I mentioned. It knows how to download linux-2.6.M and how to apply -rcN, -gitN, and/or -mmN patches to the base (linux-2.6.M). E.g.: grab_kernel 2.6.23-rc3-git6 $PWD or grab_kernel 2.6.23-rc3-mm1 $PWD -- ~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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On 8/28/07, Randy Dunlap [EMAIL PROTECTED] wrote: Michael Evans wrote: On 8/28/07, Randy Dunlap [EMAIL PROTECTED] wrote: Michael Evans wrote: On 8/28/07, Bill Davidsen [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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. So I should look at the git documentation again, try to pull down Andrew's latest -mm, and see what I need to change (if anything) to patch against it? (I would probably only verify that boots once my self given the other testing this has already seen and how often mm breaks things my mythtv box likes, such as nvidia-drivers, etc,) -mm is available only as a patchset, not via git. There has been a git version of it, but it's not currently working and hasn't been for 2 months or so. I mostly use the grab_kernel script that I mentioned. It knows how to download linux-2.6.M and how to apply -rcN, -gitN, and/or -mmN patches to the base (linux-2.6.M). E.g.: grab_kernel 2.6.23-rc3-git6 $PWD or grab_kernel 2.6.23-rc3-mm1 $PWD -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** Gentoo's mm-sources is version 2.6.23-rc3-mm1, which I'd guess is close enough for an area like this. Given that I didn't need to make any changes to the patch should I just submit it to the mm for testing without rebooting in to an mm-sources kernel? I need to schedule when I do that so it would take me overnight to do so. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
Michael Evans wrote: On 8/28/07, Randy Dunlap [EMAIL PROTECTED] wrote: Michael Evans wrote: On 8/28/07, Randy Dunlap [EMAIL PROTECTED] wrote: Michael Evans wrote: On 8/28/07, Bill Davidsen [EMAIL PROTECTED] 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. Gentoo's mm-sources is version 2.6.23-rc3-mm1, which I'd guess is close enough for an area like this. Given that I didn't need to make any changes to the patch should I just submit it to the mm for testing without rebooting in to an mm-sources kernel? I need to schedule when I do that so it would take me overnight to do so. Yes, I think that you can go ahead with that, but it's up to the subsystem maintainers where/when it goes from there. -- ~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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
Michael J. Evans wrote: On Monday 27 August 2007, Randy Dunlap wrote: On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote: = --- linux/drivers/md/md.c.orig 2007-08-21 03:19:42.511576248 -0700 +++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700 @@ -24,4 +24,6 @@ + - autodetect dev list not array: Michael J. Evans <[EMAIL PROTECTED]> + Nowadays we use an SCM for such comments, not the source file(s). SCM? Is this automatic, where do I go to see it? See Documentation/SubmittingPatches: 14) The canonical patch format: The canonical patch message body contains the following: - A "from" line specifying the patch author. - An empty line. - The body of the explanation, which will be copied to the permanent changelog to describe this patch. - The "Signed-off-by:" lines, described above, which will also go in the changelog. - A marker line containing simply "---". - Any additional comments not suitable for the changelog. - The actual patch (diff output). so just put whatever you want to be in the permanent SCM logs into the "body of the explanation" part of the email. -- ~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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On Monday 27 August 2007, Randy Dunlap wrote:
> On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote:
>
> > =
> > --- linux/drivers/md/md.c.orig 2007-08-21 03:19:42.511576248 -0700
> > +++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700
> > @@ -24,4 +24,6 @@
> >
> > + - autodetect dev list not array: Michael J. Evans
<[EMAIL PROTECTED]>
> > +
>
> Nowadays we use an SCM for such comments, not the source file(s).
SCM? Is this automatic, where do I go to see it?
>
> > This program is free software; you can redistribute it and/or modify
> > it under the terms of the GNU General Public License as published by
> > the Free Software Foundation; either version 2, or (at your option)
> > @@ -5752,13 +5754,26 @@ void md_autodetect_dev(dev_t dev)
> > * Searches all registered partitions for autorun RAID arrays
> > * at boot time.
> > */
> > -static dev_t detected_devices[128];
> > -static int dev_cnt;
> > +
> > +static LIST_HEAD(all_detected_devices);
> > +struct detected_devices_node {
> > + struct list_head list;
> > + dev_t dev;
> > +};
> >
> > void md_autodetect_dev(dev_t dev)
> > {
> > - if (dev_cnt >= 0 && dev_cnt < 127)
> > - detected_devices[dev_cnt++] = dev;
> > + struct detected_devices_node *node_detected_dev;
> > + char strbuf[BDEVNAME_SIZE];
> > +
> > + node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
>
> Drop the trailing '\', as someone has already commented on.
>
I thought I had fixed that, I must have copied the unfixed version out of the
way when I made the other changes to it.
> > + if (node_detected_dev) {
> > + node_detected_dev->dev = dev;
> > + list_add_tail(_detected_dev->list, _detected_devices);
> > + } else {
> > + printk(KERN_CRIT "md: md_autodetect_dev: kzAlloc node failed"
> > + " (null return), skipping dev(%d,%d)\n", MAJOR(dev),
> > MINOR(dev));
>
> printk() formatting is bad.
> Drop the " (null return)" and indent that line more than the
> printk line is indented.
>
> > + }
> > }
> >
> >
>
> ---
> ~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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote:
> Note: between 2.6.22 and 2.6.23-rc3-git5
> rdev = md_import_device(dev,0, 0);
> became
> rdev = md_import_device(dev,0, 90);
> So the patch has been edited to patch around that line. (might be fuzzy)
so you should update the patch to the latest mainline.
It's up to the (RAID) maintainer(s) if they want to merge a patch with fuzz.
Andrew may fix it up. Linus wouldn't accept it with fuzz.
> Signed-off-by: Michael J. Evans <[EMAIL PROTECTED]>
> =
> --- linux/drivers/md/md.c.orig2007-08-21 03:19:42.511576248 -0700
> +++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700
> @@ -24,4 +24,6 @@
>
> + - autodetect dev list not array: Michael J. Evans <[EMAIL PROTECTED]>
> +
Nowadays we use an SCM for such comments, not the source file(s).
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 2, or (at your option)
> @@ -5752,13 +5754,26 @@ void md_autodetect_dev(dev_t dev)
> * Searches all registered partitions for autorun RAID arrays
> * at boot time.
> */
> -static dev_t detected_devices[128];
> -static int dev_cnt;
> +
> +static LIST_HEAD(all_detected_devices);
> +struct detected_devices_node {
> + struct list_head list;
> + dev_t dev;
> +};
>
> void md_autodetect_dev(dev_t dev)
> {
> - if (dev_cnt >= 0 && dev_cnt < 127)
> - detected_devices[dev_cnt++] = dev;
> + struct detected_devices_node *node_detected_dev;
> + char strbuf[BDEVNAME_SIZE];
> +
> + node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
Drop the trailing '\', as someone has already commented on.
> + if (node_detected_dev) {
> + node_detected_dev->dev = dev;
> + list_add_tail(_detected_dev->list, _detected_devices);
> + } else {
> + printk(KERN_CRIT "md: md_autodetect_dev: kzAlloc node failed"
> + " (null return), skipping dev(%d,%d)\n", MAJOR(dev),
> MINOR(dev));
printk() formatting is bad.
Drop the " (null return)" and indent that line more than the
printk line is indented.
> + }
> }
>
>
---
~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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch v3 1/1] md: Software Raid autodetect dev list not array
From: Michael J. Evans <[EMAIL PROTECTED]>
In current release kernels the md module (Software RAID) uses a static array
(dev_t[128]) to store partition/device info temporarily for autostart.
This patch replaces that static array with a list.
Signed-off-by: Michael J. Evans <[EMAIL PROTECTED]>
---
Sorry, it looks like I hit reply instead of reply to all yesterday.
Version 3:
md_autodetect_dev failure message is now more usefully verbose.
removed unused i_found that was leftover from initial verification.
Thank you Randy Dunlap for pointing where INT_MAX was, fixme fixed.
Version 2:
using list_add_tail, and corrected missing i_passed++;.
removed sections of code that would never be reached.
Version 1:
The data/structures are only used within md.c, and very close together.
However I wonder if the structural information shouldn't go in to...
../../include/linux/raid/md_k.h instead.
I discovered this (and that the devices are added as disks/partitions are
discovered at boot) while I was debugging why only one of my MD arrays would
come up whole, while all the others were short a disk.
I eventually discovered that it was enumerating through all of 9 of my 11 hds
(2 had only 4 partitions apiece) while the other 9 have 15 partitions
(I wanted 64 per drive...). The last partition of the 8th drive in my 9 drive
raid 5 sets wasn't added, thus making the final md array short both a parity
and data disk, and it was started later, elsewhere.
Subject: [patch 1/1] md: Software Raid autodetect dev list not array
SOFTWARE RAID (Multiple Disks) SUPPORT
P: Ingo Molnar
M: [EMAIL PROTECTED]
P: Neil Brown
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Supported
Unless you have a reason NOT to do so, CC [EMAIL PROTECTED]
12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
enabled.
It has been tested with CONFIG_SMP set and unset (Different x86_64 systems).
It has been tested with CONFIG_PREEMPT set and unset (same system).
CONFIG_LBD isn't even an option in my .config file.
Note: between 2.6.22 and 2.6.23-rc3-git5
rdev = md_import_device(dev,0, 0);
became
rdev = md_import_device(dev,0, 90);
So the patch has been edited to patch around that line. (might be fuzzy)
Signed-off-by: Michael J. Evans <[EMAIL PROTECTED]>
=
--- linux/drivers/md/md.c.orig 2007-08-21 03:19:42.511576248 -0700
+++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700
@@ -24,4 +24,6 @@
+ - autodetect dev list not array: Michael J. Evans <[EMAIL PROTECTED]>
+
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
@@ -5752,13 +5754,26 @@ void md_autodetect_dev(dev_t dev)
* Searches all registered partitions for autorun RAID arrays
* at boot time.
*/
-static dev_t detected_devices[128];
-static int dev_cnt;
+
+static LIST_HEAD(all_detected_devices);
+struct detected_devices_node {
+ struct list_head list;
+ dev_t dev;
+};
void md_autodetect_dev(dev_t dev)
{
- if (dev_cnt >= 0 && dev_cnt < 127)
- detected_devices[dev_cnt++] = dev;
+ struct detected_devices_node *node_detected_dev;
+ char strbuf[BDEVNAME_SIZE];
+
+ node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
+ if (node_detected_dev) {
+ node_detected_dev->dev = dev;
+ list_add_tail(_detected_dev->list, _detected_devices);
+ } else {
+ printk(KERN_CRIT "md: md_autodetect_dev: kzAlloc node failed"
+ " (null return), skipping dev(%d,%d)\n", MAJOR(dev),
MINOR(dev));
+ }
}
@@ -5765,7 +5760,12 @@ static void autostart_arrays(int part)
static void autostart_arrays(int part)
{
mdk_rdev_t *rdev;
- int i;
+ struct detected_devices_node *node_detected_dev;
+ dev_t dev;
+ int i_scanned, i_passed;
+
+ i_scanned = 0;
+ i_passed = 0;
printk(KERN_INFO "md: Autodetecting RAID arrays.\n");
@@ -5772,3 +5792,7 @@ static void autostart_arrays(int part)
- for (i = 0; i < dev_cnt; i++) {
- dev_t dev = detected_devices[i];
-
+ while (!list_empty(_detected_devices) && i_scanned < INT_MAX) {
+ i_scanned++;
+ node_detected_dev = list_entry(all_detected_devices.next,
+ struct detected_devices_node, list);
+ list_del(_detected_dev->list);
+ dev = node_detected_dev->dev;
+ kfree(node_detected_dev);
@@ -5781,8 +5807,11 @@ static void autostart_arrays(int part)
continue;
}
[patch v3 1/1] md: Software Raid autodetect dev list not array
From: Michael J. Evans [EMAIL PROTECTED]
In current release kernels the md module (Software RAID) uses a static array
(dev_t[128]) to store partition/device info temporarily for autostart.
This patch replaces that static array with a list.
Signed-off-by: Michael J. Evans [EMAIL PROTECTED]
---
Sorry, it looks like I hit reply instead of reply to all yesterday.
Version 3:
md_autodetect_dev failure message is now more usefully verbose.
removed unused i_found that was leftover from initial verification.
Thank you Randy Dunlap for pointing where INT_MAX was, fixme fixed.
Version 2:
using list_add_tail, and corrected missing i_passed++;.
removed sections of code that would never be reached.
Version 1:
The data/structures are only used within md.c, and very close together.
However I wonder if the structural information shouldn't go in to...
../../include/linux/raid/md_k.h instead.
I discovered this (and that the devices are added as disks/partitions are
discovered at boot) while I was debugging why only one of my MD arrays would
come up whole, while all the others were short a disk.
I eventually discovered that it was enumerating through all of 9 of my 11 hds
(2 had only 4 partitions apiece) while the other 9 have 15 partitions
(I wanted 64 per drive...). The last partition of the 8th drive in my 9 drive
raid 5 sets wasn't added, thus making the final md array short both a parity
and data disk, and it was started later, elsewhere.
Subject: [patch 1/1] md: Software Raid autodetect dev list not array
SOFTWARE RAID (Multiple Disks) SUPPORT
P: Ingo Molnar
M: [EMAIL PROTECTED]
P: Neil Brown
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
S: Supported
Unless you have a reason NOT to do so, CC [EMAIL PROTECTED]
12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously
enabled.
It has been tested with CONFIG_SMP set and unset (Different x86_64 systems).
It has been tested with CONFIG_PREEMPT set and unset (same system).
CONFIG_LBD isn't even an option in my .config file.
Note: between 2.6.22 and 2.6.23-rc3-git5
rdev = md_import_device(dev,0, 0);
became
rdev = md_import_device(dev,0, 90);
So the patch has been edited to patch around that line. (might be fuzzy)
Signed-off-by: Michael J. Evans [EMAIL PROTECTED]
=
--- linux/drivers/md/md.c.orig 2007-08-21 03:19:42.511576248 -0700
+++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700
@@ -24,4 +24,6 @@
+ - autodetect dev list not array: Michael J. Evans [EMAIL PROTECTED]
+
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
@@ -5752,13 +5754,26 @@ void md_autodetect_dev(dev_t dev)
* Searches all registered partitions for autorun RAID arrays
* at boot time.
*/
-static dev_t detected_devices[128];
-static int dev_cnt;
+
+static LIST_HEAD(all_detected_devices);
+struct detected_devices_node {
+ struct list_head list;
+ dev_t dev;
+};
void md_autodetect_dev(dev_t dev)
{
- if (dev_cnt = 0 dev_cnt 127)
- detected_devices[dev_cnt++] = dev;
+ struct detected_devices_node *node_detected_dev;
+ char strbuf[BDEVNAME_SIZE];
+
+ node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
+ if (node_detected_dev) {
+ node_detected_dev-dev = dev;
+ list_add_tail(node_detected_dev-list, all_detected_devices);
+ } else {
+ printk(KERN_CRIT md: md_autodetect_dev: kzAlloc node failed
+(null return), skipping dev(%d,%d)\n, MAJOR(dev),
MINOR(dev));
+ }
}
@@ -5765,7 +5760,12 @@ static void autostart_arrays(int part)
static void autostart_arrays(int part)
{
mdk_rdev_t *rdev;
- int i;
+ struct detected_devices_node *node_detected_dev;
+ dev_t dev;
+ int i_scanned, i_passed;
+
+ i_scanned = 0;
+ i_passed = 0;
printk(KERN_INFO md: Autodetecting RAID arrays.\n);
@@ -5772,3 +5792,7 @@ static void autostart_arrays(int part)
- for (i = 0; i dev_cnt; i++) {
- dev_t dev = detected_devices[i];
-
+ while (!list_empty(all_detected_devices) i_scanned INT_MAX) {
+ i_scanned++;
+ node_detected_dev = list_entry(all_detected_devices.next,
+ struct detected_devices_node, list);
+ list_del(node_detected_dev-list);
+ dev = node_detected_dev-dev;
+ kfree(node_detected_dev);
@@ -5781,8 +5807,11 @@ static void autostart_arrays(int part)
continue;
}
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote:
Note: between 2.6.22 and 2.6.23-rc3-git5
rdev = md_import_device(dev,0, 0);
became
rdev = md_import_device(dev,0, 90);
So the patch has been edited to patch around that line. (might be fuzzy)
so you should update the patch to the latest mainline.
It's up to the (RAID) maintainer(s) if they want to merge a patch with fuzz.
Andrew may fix it up. Linus wouldn't accept it with fuzz.
Signed-off-by: Michael J. Evans [EMAIL PROTECTED]
=
--- linux/drivers/md/md.c.orig2007-08-21 03:19:42.511576248 -0700
+++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700
@@ -24,4 +24,6 @@
+ - autodetect dev list not array: Michael J. Evans [EMAIL PROTECTED]
+
Nowadays we use an SCM for such comments, not the source file(s).
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
@@ -5752,13 +5754,26 @@ void md_autodetect_dev(dev_t dev)
* Searches all registered partitions for autorun RAID arrays
* at boot time.
*/
-static dev_t detected_devices[128];
-static int dev_cnt;
+
+static LIST_HEAD(all_detected_devices);
+struct detected_devices_node {
+ struct list_head list;
+ dev_t dev;
+};
void md_autodetect_dev(dev_t dev)
{
- if (dev_cnt = 0 dev_cnt 127)
- detected_devices[dev_cnt++] = dev;
+ struct detected_devices_node *node_detected_dev;
+ char strbuf[BDEVNAME_SIZE];
+
+ node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
Drop the trailing '\', as someone has already commented on.
+ if (node_detected_dev) {
+ node_detected_dev-dev = dev;
+ list_add_tail(node_detected_dev-list, all_detected_devices);
+ } else {
+ printk(KERN_CRIT md: md_autodetect_dev: kzAlloc node failed
+ (null return), skipping dev(%d,%d)\n, MAJOR(dev),
MINOR(dev));
printk() formatting is bad.
Drop the (null return) and indent that line more than the
printk line is indented.
+ }
}
---
~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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
On Monday 27 August 2007, Randy Dunlap wrote:
On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote:
=
--- linux/drivers/md/md.c.orig 2007-08-21 03:19:42.511576248 -0700
+++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700
@@ -24,4 +24,6 @@
+ - autodetect dev list not array: Michael J. Evans
[EMAIL PROTECTED]
+
Nowadays we use an SCM for such comments, not the source file(s).
SCM? Is this automatic, where do I go to see it?
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2, or (at your option)
@@ -5752,13 +5754,26 @@ void md_autodetect_dev(dev_t dev)
* Searches all registered partitions for autorun RAID arrays
* at boot time.
*/
-static dev_t detected_devices[128];
-static int dev_cnt;
+
+static LIST_HEAD(all_detected_devices);
+struct detected_devices_node {
+ struct list_head list;
+ dev_t dev;
+};
void md_autodetect_dev(dev_t dev)
{
- if (dev_cnt = 0 dev_cnt 127)
- detected_devices[dev_cnt++] = dev;
+ struct detected_devices_node *node_detected_dev;
+ char strbuf[BDEVNAME_SIZE];
+
+ node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
Drop the trailing '\', as someone has already commented on.
I thought I had fixed that, I must have copied the unfixed version out of the
way when I made the other changes to it.
+ if (node_detected_dev) {
+ node_detected_dev-dev = dev;
+ list_add_tail(node_detected_dev-list, all_detected_devices);
+ } else {
+ printk(KERN_CRIT md: md_autodetect_dev: kzAlloc node failed
+(null return), skipping dev(%d,%d)\n, MAJOR(dev),
MINOR(dev));
printk() formatting is bad.
Drop the (null return) and indent that line more than the
printk line is indented.
+ }
}
---
~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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v3 1/1] md: Software Raid autodetect dev list not array
Michael J. Evans wrote: On Monday 27 August 2007, Randy Dunlap wrote: On Mon, 27 Aug 2007 15:16:21 -0700 Michael J. Evans wrote: = --- linux/drivers/md/md.c.orig 2007-08-21 03:19:42.511576248 -0700 +++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700 @@ -24,4 +24,6 @@ + - autodetect dev list not array: Michael J. Evans [EMAIL PROTECTED] + Nowadays we use an SCM for such comments, not the source file(s). SCM? Is this automatic, where do I go to see it? See Documentation/SubmittingPatches: 14) The canonical patch format: The canonical patch message body contains the following: - A from line specifying the patch author. - An empty line. - The body of the explanation, which will be copied to the permanent changelog to describe this patch. - The Signed-off-by: lines, described above, which will also go in the changelog. - A marker line containing simply ---. - Any additional comments not suitable for the changelog. - The actual patch (diff output). so just put whatever you want to be in the permanent SCM logs into the body of the explanation part of the email. -- ~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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
