Re: [PATCH] 2.6.21-git15 - Kconfig Cleanup
On Fri, 18 May 2007 15:09:53 -0400 Matt LaPlante <[EMAIL PROTECTED]> wrote: > On Fri, 18 May 2007 20:01:54 +0200 > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote: > > > > > ping? > > > > Noone disagreed, and trivial patches will be forwarded again during the > > 2.6.23 merge window. > This patch doesn't appear to have ever found its way into the trivial git after it was accepted, and as a result doesn't seem to have made it into 2.6.23 before the window closed. Was there a problem? FWIW, I have a second patch that also doesn't seem to have made it to the trivial git yet... but unlike the patch above, the second one is only a few weeks old and may just be sitting in the old inbox (http://article.gmane.org/gmane.linux.kernel/554613). Thanks, Matt > > > > > cu > > Adrian > > > > -- > > > >"Is there not promise of rain?" Ling Tan asked suddenly out > > of the darkness. There had been need of rain for many days. > >"Only a promise," Lao Er said. > >Pearl S. Buck - Dragon Seed > > > > - 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] 2.6.21-git15 - Kconfig Cleanup
On Fri, 18 May 2007 15:09:53 -0400 Matt LaPlante [EMAIL PROTECTED] wrote: On Fri, 18 May 2007 20:01:54 +0200 Adrian Bunk [EMAIL PROTECTED] wrote: On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote: ping? Noone disagreed, and trivial patches will be forwarded again during the 2.6.23 merge window. This patch doesn't appear to have ever found its way into the trivial git after it was accepted, and as a result doesn't seem to have made it into 2.6.23 before the window closed. Was there a problem? FWIW, I have a second patch that also doesn't seem to have made it to the trivial git yet... but unlike the patch above, the second one is only a few weeks old and may just be sitting in the old inbox (http://article.gmane.org/gmane.linux.kernel/554613). Thanks, Matt cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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] 2.6.21-git15 - Kconfig Cleanup
On Fri, 18 May 2007 20:01:54 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote: > > > ping? > > Noone disagreed, and trivial patches will be forwarded again during the > 2.6.23 merge window. Ok, I didn't know it would be acceptable without an ack from someone... (is Randy on vacation? :) I know we've discussed the logic behind trivial merges going in prior to RC candidates, and generally I think it's sound enough (we don't want to disrupt the merging of patches that actually "matter," etc). I don't want to create a redundant conversation here, but I'm compelled to ask for opinions on this... I think the Kconfigs are a fairly prominent kernel feature, and would expect a lot of systems people will be seeing them when the new version goes final. That also means that a lot more people will be seeing the "trivial" errors in spelling or grammar that are being left in until the next version. In this round, for example, the new blackfin entries were really in need of some love. I don't really know how many people will report such things, or submit duplicate patches for them before we actually get to the next kernel cycle, but it seems like a waste to me. I don't really care so much about fixes to the Documentation texts or source comments because, in my estimation, they probably have a much smaller audience than the kernel configuration interface. I guess I'm just more sensitive to the presentation aspects of a project than the average developer, but I can't help feel it's a shame when we're willing to show the public such an unpolished face in a "final" product. To me, good code is taken down a notch by haphazard presentation. Thoughts? Cheers, Matt > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed > -- Matt LaPlante CCNP, CCDP, A+, Linux+, CQS [EMAIL PROTECTED] - 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] 2.6.21-git15 - Kconfig Cleanup
On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote: > ping? Noone disagreed, and trivial patches will be forwarded again during the 2.6.23 merge window. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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] 2.6.21-git15 - Kconfig Cleanup
ping? On Fri, 11 May 2007 22:05:01 -0400 Matt LaPlante <[EMAIL PROTECTED]> wrote: > Fix misc small issues/typos/grammar in Kconfigs for 2.6.21-git15. > > Signed-off-by: Matt LaPlante <[EMAIL PROTECTED]> > -- > > diff -ru a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig > --- a/arch/arm/plat-s3c24xx/Kconfig 2007-04-25 23:08:32.0 -0400 > +++ b/arch/arm/plat-s3c24xx/Kconfig 2007-05-11 21:44:06.0 -0400 > @@ -70,7 +70,7 @@ > help > Set the chunksize in Kilobytes of the CRC for checking memory > corruption over suspend and resume. A smaller value will mean that > - the CRC data block will take more memory, but wil identify any > + the CRC data block will take more memory, but will identify any > faults with better precision. > > See > diff -ru a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig > --- a/arch/blackfin/Kconfig 2007-05-11 20:32:24.0 -0400 > +++ b/arch/blackfin/Kconfig 2007-05-11 21:33:28.0 -0400 > @@ -435,100 +435,100 @@ > default y > help > If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked > - into L1 instruction memory.(less latency) > + into L1 instruction memory. (less latency) > > config EXCPT_IRQ_SYSC_L1 > - bool "Locate entire ASM lowlevel excepetion / interrupt - Syscall and > CPLB handler code in L1 Memory" > + bool "Locate entire ASM lowlevel exception / interrupt - Syscall and > CPLB handler code in L1 Memory" > default y > help > - If enabled entire ASM lowlevel exception and interrupt entry code > (STORE/RESTORE CONTEXT) is linked > - into L1 instruction memory.(less latency) > + If enabled, the entire ASM lowlevel exception and interrupt entry > code > + (STORE/RESTORE CONTEXT) is linked into L1 instruction memory. (less > latency) > > config DO_IRQ_L1 > bool "Locate frequently called do_irq dispatcher function in L1 Memory" > default y > help > - If enabled frequently called do_irq dispatcher function is linked > - into L1 instruction memory.(less latency) > + If enabled, the frequently called do_irq dispatcher function is linked > + into L1 instruction memory. (less latency) > > config CORE_TIMER_IRQ_L1 > bool "Locate frequently called timer_interrupt() function in L1 Memory" > default y > help > - If enabled frequently called timer_interrupt() function is linked > - into L1 instruction memory.(less latency) > + If enabled, the frequently called timer_interrupt() function is linked > + into L1 instruction memory. (less latency) > > config IDLE_L1 > bool "Locate frequently idle function in L1 Memory" > default y > help > - If enabled frequently called idle function is linked > - into L1 instruction memory.(less latency) > + If enabled, the frequently called idle function is linked > + into L1 instruction memory. (less latency) > > config SCHEDULE_L1 > bool "Locate kernel schedule function in L1 Memory" > default y > help > - If enabled frequently called kernel schedule is linked > - into L1 instruction memory.(less latency) > + If enabled, the frequently called kernel schedule is linked > + into L1 instruction memory. (less latency) > > config ARITHMETIC_OPS_L1 > bool "Locate kernel owned arithmetic functions in L1 Memory" > default y > help > If enabled arithmetic functions are linked > - into L1 instruction memory.(less latency) > + into L1 instruction memory. (less latency) > > config ACCESS_OK_L1 > bool "Locate access_ok function in L1 Memory" > default y > help > - If enabled access_ok function is linked > - into L1 instruction memory.(less latency) > + If enabled, the access_ok function is linked > + into L1 instruction memory. (less latency) > > config MEMSET_L1 > bool "Locate memset function in L1 Memory" > default y > help > - If enabled memset function is linked > - into L1 instruction memory.(less latency) > + If enabled, the memset function is linked > + into L1 instruction memory. (less latency) > > config MEMCPY_L1 > bool "Locate memcpy function in L1 Memory" > default y > help > - If enabled memcpy function is linked > - into L1 instruction memory.(less latency) > + If enabled, the memcpy function is linked > + into L1 instruction memory. (less latency) > > config SYS_BFIN_SPINLOCK_L1 > bool "Locate sys_bfin_spinlock function in L1 Memory" > default y > help > - If enabled sys_bfin_spinlock function is linked > - into L1 instruction memory.(less latency) > + If enabled, the sys_bfin_spinlock function is linked > + into L1 instruction memory. (less latency) > > config
Re: [PATCH] 2.6.21-git15 - Kconfig Cleanup
ping? On Fri, 11 May 2007 22:05:01 -0400 Matt LaPlante [EMAIL PROTECTED] wrote: Fix misc small issues/typos/grammar in Kconfigs for 2.6.21-git15. Signed-off-by: Matt LaPlante [EMAIL PROTECTED] -- diff -ru a/arch/arm/plat-s3c24xx/Kconfig b/arch/arm/plat-s3c24xx/Kconfig --- a/arch/arm/plat-s3c24xx/Kconfig 2007-04-25 23:08:32.0 -0400 +++ b/arch/arm/plat-s3c24xx/Kconfig 2007-05-11 21:44:06.0 -0400 @@ -70,7 +70,7 @@ help Set the chunksize in Kilobytes of the CRC for checking memory corruption over suspend and resume. A smaller value will mean that - the CRC data block will take more memory, but wil identify any + the CRC data block will take more memory, but will identify any faults with better precision. See file:Documentation/arm/Samsung-S3C24XX/Suspend.txt diff -ru a/arch/blackfin/Kconfig b/arch/blackfin/Kconfig --- a/arch/blackfin/Kconfig 2007-05-11 20:32:24.0 -0400 +++ b/arch/blackfin/Kconfig 2007-05-11 21:33:28.0 -0400 @@ -435,100 +435,100 @@ default y help If enabled interrupt entry code (STORE/RESTORE CONTEXT) is linked - into L1 instruction memory.(less latency) + into L1 instruction memory. (less latency) config EXCPT_IRQ_SYSC_L1 - bool Locate entire ASM lowlevel excepetion / interrupt - Syscall and CPLB handler code in L1 Memory + bool Locate entire ASM lowlevel exception / interrupt - Syscall and CPLB handler code in L1 Memory default y help - If enabled entire ASM lowlevel exception and interrupt entry code (STORE/RESTORE CONTEXT) is linked - into L1 instruction memory.(less latency) + If enabled, the entire ASM lowlevel exception and interrupt entry code + (STORE/RESTORE CONTEXT) is linked into L1 instruction memory. (less latency) config DO_IRQ_L1 bool Locate frequently called do_irq dispatcher function in L1 Memory default y help - If enabled frequently called do_irq dispatcher function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called do_irq dispatcher function is linked + into L1 instruction memory. (less latency) config CORE_TIMER_IRQ_L1 bool Locate frequently called timer_interrupt() function in L1 Memory default y help - If enabled frequently called timer_interrupt() function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called timer_interrupt() function is linked + into L1 instruction memory. (less latency) config IDLE_L1 bool Locate frequently idle function in L1 Memory default y help - If enabled frequently called idle function is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called idle function is linked + into L1 instruction memory. (less latency) config SCHEDULE_L1 bool Locate kernel schedule function in L1 Memory default y help - If enabled frequently called kernel schedule is linked - into L1 instruction memory.(less latency) + If enabled, the frequently called kernel schedule is linked + into L1 instruction memory. (less latency) config ARITHMETIC_OPS_L1 bool Locate kernel owned arithmetic functions in L1 Memory default y help If enabled arithmetic functions are linked - into L1 instruction memory.(less latency) + into L1 instruction memory. (less latency) config ACCESS_OK_L1 bool Locate access_ok function in L1 Memory default y help - If enabled access_ok function is linked - into L1 instruction memory.(less latency) + If enabled, the access_ok function is linked + into L1 instruction memory. (less latency) config MEMSET_L1 bool Locate memset function in L1 Memory default y help - If enabled memset function is linked - into L1 instruction memory.(less latency) + If enabled, the memset function is linked + into L1 instruction memory. (less latency) config MEMCPY_L1 bool Locate memcpy function in L1 Memory default y help - If enabled memcpy function is linked - into L1 instruction memory.(less latency) + If enabled, the memcpy function is linked + into L1 instruction memory. (less latency) config SYS_BFIN_SPINLOCK_L1 bool Locate sys_bfin_spinlock function in L1 Memory default y help - If enabled sys_bfin_spinlock function is linked - into L1 instruction memory.(less latency) + If enabled, the sys_bfin_spinlock function is linked + into L1 instruction memory. (less latency) config IP_CHECKSUM_L1 bool Locate IP Checksum function in L1 Memory default n help -
Re: [PATCH] 2.6.21-git15 - Kconfig Cleanup
On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote: ping? Noone disagreed, and trivial patches will be forwarded again during the 2.6.23 merge window. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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] 2.6.21-git15 - Kconfig Cleanup
On Fri, 18 May 2007 20:01:54 +0200 Adrian Bunk [EMAIL PROTECTED] wrote: On Fri, May 18, 2007 at 01:04:41PM -0400, Matt LaPlante wrote: ping? Noone disagreed, and trivial patches will be forwarded again during the 2.6.23 merge window. Ok, I didn't know it would be acceptable without an ack from someone... (is Randy on vacation? :) I know we've discussed the logic behind trivial merges going in prior to RC candidates, and generally I think it's sound enough (we don't want to disrupt the merging of patches that actually matter, etc). I don't want to create a redundant conversation here, but I'm compelled to ask for opinions on this... I think the Kconfigs are a fairly prominent kernel feature, and would expect a lot of systems people will be seeing them when the new version goes final. That also means that a lot more people will be seeing the trivial errors in spelling or grammar that are being left in until the next version. In this round, for example, the new blackfin entries were really in need of some love. I don't really know how many people will report such things, or submit duplicate patches for them before we actually get to the next kernel cycle, but it seems like a waste to me. I don't really care so much about fixes to the Documentation texts or source comments because, in my estimation, they probably have a much smaller audience than the kernel configuration interface. I guess I'm just more sensitive to the presentation aspects of a project than the average developer, but I can't help feel it's a shame when we're willing to show the public such an unpolished face in a final product. To me, good code is taken down a notch by haphazard presentation. Thoughts? Cheers, Matt cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- Matt LaPlante CCNP, CCDP, A+, Linux+, CQS [EMAIL PROTECTED] - 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/
